Run automation rule for all merged issues and once for the entire pull request

Question

Here is a very common scenario:

If a pull request is merged I would like to transition all issues mentioned in the pull request to a new status, set the fix version and afterwards release the version,

This automation rule is triggered once for each referenced issue. All issues are tagged with the correct fix version and are transitioned to done, this part is working fine.

My problem is that after this rule has completed I would like to release the version automatically, If I add a new block at the end like shown above it will attempt to release the version for each issue that triggered the rule.

Question: How can I transition all issues in a pull request and just have it trigger the release version just one time for the pull request after the above automation has completed?

Bill Sheboy · Answer

One challenge with a scenario like this is automation rule branching: branches run on more than one issue run asynchronously and in parallel, and there is no guarantee when they will finish...up until the very last step of the rule.  I believe there are suggestions to add a "wait until completed" for branches, similar to the send web request action.

Consider instead if you can break up the rule in to multiple phases.  Is there a way you can set the fix versions prior to the merge?  If so, you could try:

* one rule (triggered on merge) to transition the issues, and
* a second one (triggered on transition) to check if all siblings with the same fix version have reached your "review done" status, and then release the respective version one time

Kilian Brachtendorf_l4k74p · Answer

Hi Bill,

thank you for your response, the additional check outside of the original branch was just to do some tests. Since I removed the lower condition and moved it to a different rule in order to trigger the release once a pipeline finished it's execution.

After my last deployment this pipeline ran for each issue associated with the pull request:

----

I fail to see how adding those steps:

* action: lookup issues with JQL to find the issues in the earliest unreleased version* project = yourProjectName AND fixVersion = earliestUnreleasedVersion(yourProjectName)

* action: release version, using the fixVersion name from the first issue in the lookup* {{lookupIssues.first.fixVersion.name}}

wouldn't this still trigger the automation rule multiple times and just lead to the same race condition between releasing the version and creating a new on in a different trigger?

Simply put, how can I release a version after a pipeline has succeeded or alternatively a pull request has been sucessfully merged.

This shouldn't be a hard task, I just miss something elementary here.

Bill Sheboy · Answer

Hi @Kilian Brachtendorf -- Welcome to the Atlassian Community!

First thing...I see two conditions are checking if the PR destination branch is staging, and one of them is outside of your if/else conditions.  Is that correct for your scenario?

Back to your question...One way to do this is to use lookup issues and JQL to drive this with the function earliestUnreleasedVersion() ...such as this:

* ...your rule steps
* your condition to test if the PR destination branch is staging plus any adjustments you may make (see above)
* action: lookup issues with JQL to find the issues in the earliest unreleased version* project = yourProjectName AND fixVersion = earliestUnreleasedVersion(yourProjectName)

* action: release version, using the fixVersion name from the first issue in the lookup* {{lookupIssues.first.fixVersion.name}}

One more...when posting images of rules for questions, consider using a browser addon or screen capture which supports scrolling.  That can help to have the entire rule in one image for context.

Kind regards,
Bill