Set new version to issue based on partial version name criteria

[Dave F]

Sorry, the description of our current state and where I've got to is necessarily long...

We have multiple streams of delivery in our project. The small team delivers a number of distinct apps. 

We currently set up a generic version per app in advance, then give them a version number when it's time to release one of the apps. We also use a status called "Ready for Prod" to collect tasks that are ready to release, as the last step in the workflow before Done. 

At any given time we should have several "next versions" available (e.g. Calculator NextVer, Timesheet NextVer, DocFlow NextVer). As one becomes ready to release we replace NextVer with the version number (e.g. Timesheet 2.65.1927), then release the version in Jira.

We also use Components, and some of the components are a 1:1 match with the apps.

When we hit Release in Jira I have two automations run

• Transition all tasks in that version to Done
• Create a new empty NextVer version

What I'd like to do is have automation that sets the appropriate NextVer when the task transitions to "Ready for Prod" based on the Component field.

The automation step Create Version allows me to set the version number using regex - {{version.name.replaceAll("[.-9]+$|v[.-9]+$","NextVer")}}

However, the only way I see to set a version for an issue is to use the Edit Issue step and that only allows me to select from existing released versions. While this seems to remember the name not the DB ID for the release, I'm wondering if there's a more fool-proof way.

Q: Is there a way to set a version in automation using criteria based on part of the target version's name (e.g. regex or wildcard). Any ideas?

[Bill Sheboy · Accepted solution]

Hi @Dave F 

Yes, I believe that is possible.

When you edit an issue's fixVersion in a rule, you may type in a smart value expression, it will appear below the field, and then you can select it.

Now comes the harder part for your use case: what do you type in for that expression?

I can think of a couple of ways to solve this:

• Use a predictable naming convention for your application version numbers, store the current ones in a project-level Entity Properties, incrementing when a new version is created, and grab the one needed to set the version for issues.
• Call the REST API with a webrequest in the rule to get all the projects versions, and then use smart value, list filtering to find the desired value.  That will add a few seconds to the rule execution

Kind regards,
Bill

[Dave F]

I think I see what you're suggesting @Bill Sheboy. We do have a predictable next version name courtesy of the automations I mention; their names literally end with "NextVer" and do not have any version number. However the Edit Issue step in automations only allows me to select from existing released versions, not planned releases. Also, I can't guarantee someone won't edit the version name before it's released.

Setting the Entity level property with automation then calling it later still leaves me with a static value I have to assume will be there when the time comes. What I'm hoping to do is look for the version name where the first part of the version name is known, but the end may not be, which is why I was hoping regex might be an option. 

The webhook option looks promising though, however even though I can get the API URI to work in the browser, the automation's validate option fails with 405 error, and I'm not in a good position to investigate.

[Bill Sheboy]

Hmmm...You noted this:

What I'd like to do is have automation that sets the appropriate NextVer when the task transitions to "Ready for Prod" based on the Component field.

That seems to indicate you have Component values to indicate the product areas, and so the releases to use.  For example, Calculator, Timesheet, DocFlow, etc.)  Let's assume there is one-and-only-one Component assigned to the issue.

What if within that rule you use a lookup issues action with JQL to find the previous version for that Component, extract the value, and then increment using your standard naming convention?

The JQL for the lookup issues action would be something like this to get the done issues for that component:

project = myProjectName AND Component = {{triggerIssue.components.first.name}} AND fixVersion IS NOT EMPTY AND statusCategory = Done ORDER BY fixVersion DESC

Lookup issues is limited to return 100 issues, but that should not matter for your need.  Now you can grab the last released fixVersion with {{lookupIssues.first.fixVersion.name}} to split out and increment your version number using the text functions.

Thoughts?

[Dave F]

I've tested the JQL in our sandpit env and get results, all with the same fix version. So the query works. Thanks for that one. I also modified it slightly so it could be used anywhere:

project = {{triggerissue.project.key}} AND Component = "{{triggerIssue.components.first.name}}" AND fixVersion IS NOT EMPTY AND statusCategory = Done ORDER BY fixVersion DESC

However {{lookupIssues.first.fixVersion.name}} and {{lookupIssues.fixVersion.name}} return nothing/null.... which turns out is the same error I make when wanting one of something that can be multiple, I drop the S off the field name.

{{lookupIssues.first.fixVersions.name}} does the trick.

And for anyone else wanting to do something similar, the smart value to remove version numbers (e.g. v1.23 or 1.23) off a release and create a new similar one with NextVer on the end is:

{{lookupIssues.first.fixVersions.name.replaceAll("[.-9]+$|v[.-9]+$","NextVer")}}

 Thanks for the advice @Bill Sheboy, I couldn't have got there without you

[Bill Sheboy]

I am glad to learn that helped, and sorry on my typo on the smart value name.  I wish they were validated better prior to allowing save (or during entry): https://jira.atlassian.com/browse/JRACLOUD-75402

On that note, watch for the capitalization of smart values, such as {{lookupIssues}}.  The spacing and capitalization are not consistent for all fields/functions and sometimes the documentation is wrong too.  When in doubt, you can try this how-to article to find the correct smart values for fields: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Have a good one!

[Dave F]

Just for anyone else trying to do this or similar in future, the automation I've ended up with is below. We use Component to set the Fix version to a planned release without a number. We add the number once the build server provides it. 

1. Trigger based on transition
2. If Component is not empty
   1. Lookup with JQL:  project = {{triggerissue.project.key}} AND Component = "{{triggerIssue.components.first.name}}" AND fixVersion IS NOT EMPTY AND status = Done ORDER BY key DESC
3. If all match
   {{lookupIssues.fixVersions.size}} > 1
   {{components.name.size}} = 1
   
   1. Edit issue. Set Fix version to: 
      

      {{lookupIssues.first.fixVersions.name.replaceAll("[.-9]+$|v[.-9]+$","NextVer")}}

The minor modifications from Bill's suggestion:

• If Component not empty check, because the JQL will err if that field is empty
• If all match, so we don't have empty or multiple of either Components or Fix version
• Changes the JQL to only find released versions, not the current planned unreleased version (e.g. exclude "Calc app NextVer") assigned to WIP tasks