Jira Automation for When a deployment to Production succeeds → Then Release version runs

[Shalini.Saravanan-extern]

We have an automation to run When a deployment to Production succeeds → then release version, If we have 10 tickets tied to release then the automation runs 10 times. And another automation to trigger mail and teams notification about the release which is also running 10 times and 10 email and 10 messages triggered.

How to restrict this to run the notification only once?

[Bill Sheboy]

Hi @Shalini.Saravanan-extern 

For a question like this, I recommend posting images of your complete rules and the audit log details showing the rule execution.  Those will provide context for the community to offer suggestions.

Until we see those...

As you have learned, some of those DevOps triggers fire for each issue, which is unhelpful when you want to send one notification (e.g., email and message) about the results/progress.

One way to mitigate this is to add conditions to your second rule such that the notification only sends after the last item is updated.  You do not indicate the trigger for your second rule.  Let's assume it is issue transitioned.  For example...

First rule:

• triggered deployment to Production,
• releases the version, and
• transitions the issue to some status

Second rule

• triggered on issue transition
• sends email
• sends message

You could modify your second rule as follows to send only one notification

• triggered on issue transition
• using a JQL condition, or lookup issues and advanced comparison, confirm that all the issues in the version (for the trigger issue) are in the same, expected status
• use lookup issues to gather the issues
• send an email with all the issues referenced in the lookup

Kind regards,
Bill

[Shalini Saravanan]

When we add a condition to release the version(Status!=Released), automation not running and throwing the below error

[Bill Sheboy]

Reviewing the audit log, it appears your release names have non-alphanumeric characters in them.  Please try wrapping the smart value in quotation marks to make that work.

Also...do you want that condition in both this rule and the second one?  The first does the version release and the second rule does the email, correct?

[Shalini Saravanan]

Do you mean,currently condition added as project = ACU AND fixVersion = {{issue.fixVersions.first.name}} AND (Status != Released).

Update with quotes like --> project = ACU AND fixVersion = "{{issue.fixVersions.first.name}}" AND (Status != Released)

[Shalini Saravanan]

If this rule runs only once the mail notification will run only once too or Do we need update in mail notification too?

[Bill Sheboy]

Yes, that JQL change looks better.

And, if you want only one email that rule would also need a condition to confirm only the last issue changed sends an email. 

Please note: there could be some timing/race-conditions if multiple issues update too quickly (or slowly) at the same time; remember the rule will run for each issue and in parallel.  If that happens, a work-around for your email rule is to insert a Re-fetch Issue action after the trigger.  That should slow down the rule by about one second, helping the condition to be accurate.

[Shalini Saravanan]

After updating the JQL, notification sent 4 times, how to update the JQL to run the release version only once and not trigger for each ticket that's released

[Shalini.Saravanan-extern]

How to update the JQL to get the automation run only once? (ie) when the version is already released we don't want the rule to run again

[Bill Sheboy]

I have seen that question asked before and I do not believe there is a way; that DevOps trigger runs for each impacted issue.

One work-around is to check if the version is not yet released using an advanced compare condition, and only then proceed with the Release Version action.

[Shalini.Saravanan-extern]

Added a JQL condition project = ACU AND fixVersion = '{{issue.fixVersions.first.name}}' AND fixVersion in unreleasedVersions() to check if the version is unreleased to release the version, we expect the automation to run only once here but we are seeing multiple times action ran. 
Can you please suggest a way to update the JQL to release the version only once

[Bill Sheboy]

I have seen this symptom posted before, and I believe that is how that trigger works: once for each issue impacted.  And so there probably is no perfect way to solve this due to parallel processing and timing issues.

What you could do is call the REST API to get the version information using the webrequest action, check if the state is still "active", and only then release it.

[Shalini.Saravanan-extern]

Can you please explain more on how to call the REST API to get the version information using the webrequest action, check if the state is still "active", and only then release it

[Bill Sheboy]

Rules can use a web request action to call REST API functions, such as the ones for Jira.  Here is a how-to article walking through that: https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828

The specific function you want is to get all versions for your Jira board: https://developer.atlassian.com/cloud/jira/software/rest/api-group-board/#api-rest-agile-1-0-board-boardid-version-get

So your rule could call that REST API function to get the versions, and then use smart value, list filtering on the results: https://community.atlassian.com/t5/Automation-articles/Filtering-smart-value-lists/ba-p/1827588

All this is to check the version's "state".  If it is active it is the one you seem to want.

[Shalini.Saravanan-extern]

Added web request call and it looks like web request call runs for 0.6 seconds.

Are you saying the time delay will help the JQL to check if the version is released already?

[Bill Sheboy]

No, what I meant was the version's "state" can be checked using the call to the REST API.  Then you would only try to release one time and subsequent calls would not try it.

[Shalini.Saravanan-extern]

If I assign smart value as {{webResponses.last.body.values.name}} all the unreleased version names are listed in comma separated like below

release/Caipirinha, release/Moscow-Mule-33

Can you suggest how to check if the version name in deployed task is equal to any one of the names listed Eg : {{webResponses.last.body.values.name}} = {{issue.fixVersions.first.name}} in JQL?

or check web request CURL call to check if the release name present in released:false status
CURL call used

curl -X GET \

  'https://client.atlassian.net/rest/agile/1.0/board/97/version?released=false' \

  -H 'Authorization: Basic <api-token>'

FYI: Since we are using For:Current issue, another nested FOR couldn't be used for each webrequest returned version names. 

[Bill Sheboy]

There are a couple of ways to do this...

Use the approach you have described, and invert this: format your list like JQL and test with: {{issue.fixVersions}} IN ( your list formatted like CSV version names )

Or, you could initially filter the results of the web request (which is what I originally suggested).  Use smart value, list filtering on state being active, and the only returned versions would be want to test against / use.

[Shalini.Saravanan-extern]

We have 2 unreleased versions, I filtered the ones that are not released using 'released=false' in the web request.

Which resulted in release/Caipirinha, release/Moscow-Mule-33

Are you suggesting adding a IF condition with JQL {{issue.fixVersions.first.name}} IN {{webResponses.last.body.values.name}}?

I will test and let you know how this works

[Bill Sheboy]

Almost correct...

JQL is a simple language, and the left-side of expressions must be an issue field, not a smart value. So you want something like this:

someField someOperator someValue

When in a rule, that field is based on where you are in the rule.

You have a branch on current issue, and so the left-side would be the fixVersion field, and the right-side would be a formatted version of your webrequest response:

fixVersion IN ( {{#webResponses.last.body.values}}"{{name}}"{{^last}}, {{/}}{{/}} ) 

This will iterate over the response, creating a list of the version names to check.

[Shalini.Saravanan-extern]

Thanks Bill,

Updated the JQL as you mentioned,

We will test and get back if issue still persists.

[Shalini.Saravanan-extern]

This worked fine, thanks

[Joaquin Savanco]

Hi, @Shalini.Saravanan-extern @Bill Sheboy did you run the automation using "Rule executes when a deployment succeeds"? 

Its doesnt work, I think that im missing something betweet bitbucket and jira