Appreciate any suggestions!
I'm setting up an automation such that when an issue status is transitioned to Done, multiple releases are added to the issue's fix version field.
For context, in our project, we have 8 different releases that map to different work streams. I only want to add a subset(4) of releases to the issue fix version, which is differentiated by an ID in the release name.
Currently I have for-loop which iterates through all the releases in the project. If a release with the ID is found, then update the issue's fixVersion by adding the release.
According to the logs, the 4 releases are consistently identified correctly. However, sometimes not all 4 releases are added as fix versions. It seems to happen randomly, sometimes 4 get added, sometimes 3 and sometimes 2.
Wondering why the Edit Issue Fields action is not executing consistently every iteration when the conditions are met? Is there an order of operations problem, where editing an issue field multiple times in the same automation will cause race conditions? Is there an alternative set-up that would work better?
Hi @Yue Pan -- Welcome to the Atlassian Community!
Automation branches which could be on more-than-one-thing are executed in parallel and asynchronously, with no guaranteed processing order and that the branch may not finish until the last step of the rule.
What this means for your rule is the edits are sometime colliding / walking over the updates from each other.
For your scenario, the solution is to gather all of the releases to add and perform a single update with JSON to add them together. This can often be done with created variables, list filtering, etc.
If you show your complete rule in a single image, that will help the community advise you how this may be accomplished for your scenario.
Kind regards,
Bill
Thanks Bill! I read in an older thread that advanced branching executes async, but not regular branching, so that's a bummer.
Do you mind providing some guidance of how I might use a single JSON to achieve this? My biggest hurdle is finding a way to filter the list of {{project.versions}} to find the releases that meet my criteria.
I explored creating an array and appending desired releases to it, but didn't find any good resources for how to achieve that.
I also looked into using smart values with this function, but it didn't seem to log anything:
{{#project.versions}}
{{#not(archived)}}
{{#not(released)}}
{{#name.startsWith("ID")}},
{{/}}
{{/}}
{{/}}
{{/}}
Below is my entire rule, as well as the definition I'm using for advanced branching.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The project versions are not directly available like that in a rule. Instead they may be found for ones associated to an issue (e.g., as Fix Version values) or by calling the REST API endpoint using the Send Web Request action.
From what you describe, I believe you will need to call the REST API and send the necessary filtering parameters:
For example:
yourJiraURL/rest/api/3/project/yourProjectName/version?orderBy=name&query=ID&status=unreleased
Once you have those results in the web response, it may be filtered further using your check to start the name with "ID", and then finally iterate over the result to create the JSON. This will take several steps:
{{#webResponse.body.values}}{{#if(name.startsWith("ID"))}}{{name}}~~{{/}}{{/}}
{
"update": {
"fixVersions": [
{{#varNameList.substringBeforeLast("~~").split("~~")}}
{ "add": { "name": "{{.}}"} } {{^last}},{{/}}
{{/}}
]
}
}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Apologies for the delayed response. Thanks Bill! That worked wonders, wish we could make a feature request to have this more easily accessible.
As part of the varJSON, I was wondering if there is a way to simultaneously update the issue's status? I saw in the API docs that you can update statuses via another request, but would love to combine it altogether.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I would not advise that approach; issue transition may involve lots of things related to workflow, and so using the specific Transition Issue action is safer, like this:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Welcome to the community, @Yue Pan
You may be bumping up against an API rate limit, but I'm not sure how to check for that in Cloud sites, in Data Center, you can look at the audit log.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.