How to create and release version using Jira Automation

[Tania Schmittou]

We are using Releases as a method to group jira issues worked at a specific time together, it is not used for code release.

I have an automation that creates a version, edits the Fix Version field and releases the version but what is happening is one version is created and it is empty after the automation completes.  Audit Log shows that issues were found for the create & edit portion.  Once it's released, the issues are gone.

[Walter Buggenhout · Accepted solution]

Hi @Tania Schmittou,

In automation, when you want to edit a set of issues, it is best to start a branch in your rule to define those issues and then add the exact actions into that branch.

Since your screenshot is missing the beginning of your automation rule, it's hard to determine how you are triggering it and how you determine the set of issues to edit.

After the create version part, I would expect a branch to start: For .. - you can use a JQL branch to specify the issues you want to edit:

fixversion IS EMPTY AND Status in (Done, Delivered)

And then add the edit action to fill out the fix version into that section of the rule.

Hope this helps! 

[Tania Schmittou]

Hello Walter, please see my reply to Trudy above. thanks!

[Trudy Claspill]

Hello @Tania Schmittou 

Can you show us the complete automation rule? There are steps before the Create Version step that we need to see.

I think the problem relates to the context in which the Edit Issue and Release Version steps are running, but I need to see the rest of the rule to confirm.

The Edit Issue action needs to be executed in a context such that each issue is accessed and edited.

The Release Version action needs to be executed in a slightly different context so that the action is executed just once after all the issues have been edited.

With the portion of the rule you are showing, I don't think you have structured the rule correctly to do that.

[Tania Schmittou]

Hi Trudy! Here is my trigger, I did validate the query and got the expected issues that I anticipated.  As stated the Create Version does pick up all the issues and the Edit in my automation does set the Fix Version value.

[Trudy Claspill]

Hello @Tania Schmittou 

Is that the only step that comes prior to what you showed in the original image?

Are there any steps after what you showed in the original image?

So each week you want to create a new Version/Release, add to that release the issues that are not in any other release and match additional criterial in your Trigger JQL, and then set that new Version to "Released". Is that correct?

Can you show us the details of the Audit Log for the execution of the rule?

If my summary of your intentions for the rule are correct, then your rule is constructed incorrectly.

With a Schedule trigger that includes a JQL, each action in the rule after the trigger will be attempted for each issue returned by the JQL. In that case for each of the 1..n issues returned by the JQL, your rule is trying to execute both the Edit Issue and Release Version actions.

In this case I would recommend removing the JQL from the trigger and instead use a Branch (For Related Issues / JQL ) to retrieve and edit the issues, and move the Release Versions action outside of the branch. 

[Tania Schmittou]

Thank you Trudy.  I didn't catch that the release version was inside the if statement and have moved it out.  When I executed this previously, a version was created as Unreleased with all the issues in it so it appears the JQL from the trigger worked fine for that portion of the automation so unsure why I would need to do a branch and JQL instead.  

The release version is supposed to find (by default) the most recent Unreleased version and release it and this should be the version just created.  I will try this now that the release has been moved out of the loop and if that does not resolve my problem, I will move the JQL out of the trigger and do a branch as both you and Walter suggested.

[John Funk]

Tania!! How are you doing? Did you get this resolved? 

[Trudy Claspill]

@Tania Schmittou 

In your scenario you have a Condition to check that all issues match specified criteria. That Condition is being applied to each issue found by the Trigger JQL. It is not applying the Condition to all the issues as a group. 

But, in fact, I don't think you need that Condition at all. You should be able to include those criteria in the JQL in the trigger itself to ensure that the set of issues you select are only those where both those conditions apply.

[Tania Schmittou]

@Trudy Claspill ,

Yes, agreed, the trigger JQL could be tweaked to add the status, it already contains the Fix Version field qualifier.  I will redo my trigger JQL to be exact and remove the condition from the automation.  In this situation, where I need to edit each issue - should I add the For logic as Walter suggested or are you saying that every issue brought into the automation by the trigger will individually have action taken upon so this is unnecessary?   If so, then how do I ensure the Release Version is outside the edit actions and only happening once?  Thank you for your help here!

[Tania Schmittou]

@John Funk - Hey there!  I am working on getting this resolved, first time to work with versions in an automation.  All is good here, diving into Jira now to support it.

[John Funk]

Very good - are you the admin there now? 

[Tania Schmittou]

@John Funk - split between me and one other. 

[Trudy Claspill]

@Tania Schmittou 

In this situation, where I need to edit each issue - should I add the For logic as Walter suggested or are you saying that every issue brought into the automation by the trigger will individually have action taken upon so this is unnecessary?   If so, then how do I ensure the Release Version is outside the edit actions and only happening once? 

If you want to include the creation and release of the Version in this same rule, then you should pull the JQL from the trigger and use a For branch as suggested by @Walter Buggenhout . Otherwise the Create Version, Edit Issue, and Release Version actions will be attempted for each issue returned in the JQL by the trigger. That is the design of a Scheduled trigger with a JQL - all mainline steps are executed for each issue returned in the trigger JQL.

So, the new structure would be

Scheduled Trigger - w/o JQL
Create Version action
For Related Issues/JQL
  - Edit issue action
Release Version action

[Tania Schmittou]

@Trudy Claspill - The automation ran over the weekend to capture tickets and it created the versions, edited the tickets, released the versions (in separate automation) but when it released them, no tickets are actually in the release once again.  I even manually ran again after moving the Releases inside the main automation as you suggested to see if that was the issue and same results.  The audit log looks like everything is good but the Fix Version value seems to get wiped out after successful editing. 

[Bill Sheboy]

Hi @Tania Schmittou and all the answerers!

Apologies in advance for the long explanation below :^)

This is a tricky scenario due to how branches work.  Your rule is written to create a version, assign issues to it with a branch, and then release the version.  However...

Branches which could be on more than one thing are executed in parallel and asynchronously.  There is no guarantee of when the branch will finish...up to the moment of the last rule step completion.  Please look here to learn more: https://support.atlassian.com/cloud-automation/docs/jira-automation-branches/#Ordering-of-branch-executions  I recall there is an open suggestion to add an option for branches to wait for completion before proceeding, but I would not recommend waiting for that to be implemented.

For your rule, this means the branch to assign the issues is still running when the version is released!

There is no perfect work-around for your scenario to ensure all issues are assigned before the release happens.  You could try using a couple of methods to help:

• #1 Release the version in a separate rule
  • Rule A would create the version and assign the issues to it.  This rule is scheduled as you show to run on Friday at 10 pm.
  • Rule B would trigger later, let's assume 10:30 pm, and then release the version
• #2 Use a counter to force release only after the last issue is updated, with 2 rules again
  • Rule A is a slightly more complicated version than above
    • triggered on your schedule
    • create the version
    • use lookup issues with JQL to find the issues to update, and to identify the total issue count with {{lookupIssues.size|0}}
    • branch over the lookup issues
      • assign them to the new version...and add a comment including the name of the version and the total issue count
  • Rule B, is triggered on the adding of the comment in the particular format with your data from above  (This rule would enable the option "Allow Rule Trigger" so the first rule's actions can start it.)
    • this rule checks, with a lookup issues action, if all of the issues have been assigned to the version
    • only after that has occurred would the version release

The reasons neither of these approaches is perfect are related to timing and error-handling.  When Atlassian has an automation rule outage, it is possible scheduled rules will not run and "catch up".

For the current environment, I recommend trying the first approach, scheduling a separate rule to release the version.

Kind regards,
Bill

[Trudy Claspill]

Hello @Tania Schmittou 

You appear to have three separate actions creating three separate versions with the same name. Why is that? Or am I missing some detail from those actions?

Also, what are the details of your Edit Issue action?

[Tania Schmittou]

@Bill Sheboy  Thank you and your explanation is most enlightening about branches!  Your #1 suggestion is what I tried the first time and it still created empty releases with no issues.  I had the above automation kick off at 10:00 PM to create 3 versions in 3 separate projects, then ran the JQL to pull in the issues for all 3 projects and edit them.  Then at 11:00 PM automations kicked off to release each one (blank to pick up the most recently created version in that project. 

@Trudy Claspill Thank you as well for your persistence here, above explains that I am creating 3 versions for 3 separate projects at same time to get a team's entire set of issues for release since they span 3 projects, edit the issues and release the versions.  

 I will try Bill's #2 recommendation above.

Thank you both!