Releasing multiple versions from a single issue.

[Heather Ronnebeck]

Hey,

What I'm trying to do is create an automation that does the following: 

1. Upon being triggered by a ticket being closed, checks to see if there are any fix versions attached to the ticket.
2. Grabs the names of all versions in the fix version field on the trigger ticket.
3. Checks each version listed to see if there are any remaining open tickets. 
4. If no remaining tickets, release the version.

I had this working when there was 1 version in the fix version field, but as I'm learning, the users are having multiple versions and now I can't get the branching and array working to have each version checked in steps 3 and 4 (if applicable). 

This is one of the lookup queries I've tried for step 2. 

  fixversion in ( {{triggerissue.fixVersions.name.asJsonString.asJsonArray}} ) AND statuscategory NOT IN (Done)

Does anyone have any suggestions on how I can accomplish this? I am running in to the wall here.

Thank you!

[Bill Sheboy]

Hi @Heather Ronnebeck 

Without seeing your entire rule (and audit log details) for context...

What is the purpose of the asJsonArray added to the end of the expression?  I would expect using just asJsonString would be sufficient to produce the CSV list:

fixVersion IN ( {{triggerIssue.fixVersions.name.asJsonString}} ) ...

And...what is the scope of the rule: single-project, multiple-project, or global?  For other than single-project, perhaps use the version ID rather than the names to reduce the risk of collisions. 

fixVersion IN ( {{triggerIssue.fixVersions.id.join(", ")}} ) ...

Kind regards,
Bill

UPDATED: please see the post below using the new flatten function to merge the version values from lists-of-lists into a single list of version ID values:

https://community.atlassian.com/forums/Automation-questions/Re-Re-Releasing-multiple-versions-from-a-single-issue/qaq-p/2999095/comment-id/13947#M13947

[Heather Ronnebeck]

I was trying to pull out when there were two fix versions vs one in the rule. This is for a single project scope. 

[Heather Ronnebeck]

The format you provided did help a bit, but the error I got was "The provided smart value couldn't be resolved to an object"

[Bill Sheboy]

Hi, Heather.  Rather than suggesting two different approaches, please continue with the thread with Andrea and I will pitch in to help if an alternative is needed.

[Andrea Robbins]

Hi @Heather Ronnebeck

Here's my thoughts:

1. When ticket is resolved

2. Go through each fix version

3. Do a issue lookup to see if any issues are still open

4. If none are open, release that Fix Version

See screenshots

Note for the LookupIssues it needs to be "fixVersion in ({{fixVersionVar.id}}) AND resolution is empty" (screenshot says fixVersions it needs to be singular). Note also I haven't tested this (haven't saved it) so please let me know if this works as expected :)

[Heather Ronnebeck]

Hey, 

The issue I'm running into is that it's not having a good time pulling out those fix versions. It seems to not be able to make it an object. 

[Andrea Robbins]

Just tested the rule in my environment. Make two minor adjustments:

- Change {{lookupIssues}} to {{lookupIssues.size}} in the If: Compare two values

- Change fixversions to fixVersion in the JQL

[Andrea Robbins]

Also see if the For each: Smart value is set up as shown in the screenshot. It should only show one fix version id. It goes through each one mentioned on the issue one by one, so it knows which one to close

EDIT: I see your error now more clearly - make sure the lookup Issues component is within the branch or it won't work as expected

[Heather Ronnebeck]

Hey @Andrea Robbins 

I did the updates you're suggesting, but I am still getting the error that the provided smart value couldn't be resolved to be an object. 

I think I'm doing something wrong at the Branching step. 

[Bill Sheboy]

Heather, would you please post an image of your current complete rule and of the audit log details showing the execution (with all of the areas at the right side expanded)?  That context may help explain what you are observing.  Thanks!

[Bill Sheboy]

Hi @Heather Ronnebeck 

Just following up to check if this answered your question.  If so, please consider marking this one as "answered".  That will help others with a similar need find solutions faster.  If not, please let the community know what help you need with the rule changes.

Thanks!

[Heather Ronnebeck]

Hey @Bill Sheboy 

I'm just traveling right now from Team so I haven't had a chance to look at this again in a while. As soon as I can I'll post the automation and we can continue working on it. 

Thank you again!

[Heather Ronnebeck]

@Bill Sheboy @Andrea Robbins Here's the rule in its current state. I hope this helps. I haven't touched it since we last spoke.  

[Bill Sheboy]

Hi @Heather Ronnebeck 

Thanks for the rule image, and let's adjust some things...

First, smart values are name, spacing, and case sensitive, and the one for the Fix Versions field is {{issue.fixVersions}} so please update your log statements and the advanced branch.

Next, let's simplify the branching and only use the ID values (as those will be needed later for releasing.  Thus for the advanced branch smart value, we can use the new flatten function to combine the values (from the lists-of-lists) and get the distinct ones:

• advanced branch
  
  • smart value: {{lookupIssues.fixVersions.id.flatten.distinct}}
  • variable name: fixVersionIDVar

I added ID to the variable name to make it obvious what value it contains.  Then change the JQL for Lookup Issue inside the branch, and follow that by a condition to confirm no issues remain.  Please note well: the JQL was missing the NOT to confirm there are no remaining issues active in the version.

• action: lookup issues
  • fixVersion IN ( {{fixVersionIDVar}} ) AND Resolution IS NOT EMPTY
• smart values condition
  • first value: {{lookupIssues.size}}
  • condition: equals
  • second value: 0
• action: release the version, {{fixVersionIDVar}}