Is it possible to use workflows to automatically change the release version?

[l bascle]

We are currently using Sprints but not Versions. 

We have synched JIRA with Stories on Board, a tool to help with long-term planning. This tool is using versions, not Sprints.

I would like to create a trigger whereby if I change the value of the 'sprint' from empty to a value, that same value is copied across to 'version'. is that possible?

Essentially, I want to ensure that sprint=version without having to set them both every time manually.

[l bascle · Accepted solution]

OK both @Bill Sheboy @John Funk , I have finally managed to set it up thanks to your contributions. Thank you so much! I am summarising below for visibility

• Go to Automation Rules under JIRA settings
• Create Rule. I have created a global rule for all projects, but you could just as well create a rule per project
• CONDITION/TRIGGER: Field value changed: SPRINT.
• ACTION: Create version with version name: {{sprint.name}}
• BRANCH: for current issue
• ACTION: edit issue field 'fix versions' with {{sprint.name}} (that was the bit that was previously missing and meant my 'fix version field was blank).
  
  
  A screenshot below.
• 

[Bill Sheboy]

Great; I am glad you got it to work.  Thanks for summarizing!

[John Funk]

Yes, thanks for the response and glad it is working for you!

[Bill Sheboy]

Hi @l bascle 

Is this what you are trying to do with a rule?

• Trigger: sprint created
• Action:  create version, with the name of {{sprint.name}}

Or, change your trigger to sprint started, and then you could set the Fix Version for the included issues after the version is created using a Lookup action and JQL on the sprint field.

Best regards,

Bill

[l bascle]

exactly (if possible)

• Trigger: sprint created
• Action:  create version, with the name of {{sprint.name}}

[Bill Sheboy]

Great; please look here for documentation on how to create and manage your rules:

https://support.atlassian.com/jira-software-cloud/docs/automate-your-jira-cloud-processes-and-workflows/

[l bascle]

Gaaah sorry! At least this link has allowed me to have a little play with automation rules and understand how they work., and i realised that it was a bit different

- trigger= sprint value created/updated

- action: create/update value with the name of {{sprint.name}}

@John Funk I tried the basics of what you suggested but maybe it doesn't work because i needed to create the releases first and name them exactly the same? is that done properly

[John Funk]

Hey Bill - do you know if Automation For Jira will actually create the version if a value is added to an empty field? That's what he is trying to do. 

[Bill Sheboy]

Hi,  John -- I haven't tried that.  Instead I created the version first and then associated it to the issues.  This example below worked for me:

[l bascle]

Right, so this time this is what I have done.

- I have a sprint called 'Q4-2020'.

- i created a release called 'Q4-2020'

- i choose an issue from project and move it from backlog into sprint 'Q4-2020', and sprint name is 'Q4-2020'

- i can see a message telling me to refresh page because a rule was triggered

- i refresh issue and now there is a dropdown where there was nothing under 'fix version', but no value is chosen. 

When using JQL btw i can see that the 'backend' name of the sprint is "6", so maybe something to do with that?

[Bill Sheboy]

Hi @l bascle 

Note that in my rule example, I created the version and assigned to the issues in the rule, using the sprint name as the version name.  I suspect by creating the version manually there is some difference between the version text and what you are trying to assign in the rule.

When assigning the version, you could select the name with a smart value (as I did with {{sprint.name}}  ) or just assign to the Next Unreleased Version.

If you post your latest rule image, maybe we can see something causing what you are seeing.  Thanks!

[l bascle]

Thank you.

So I amended my flow to also have a 'create {{sprint.name}} '. 

Here is a screen grab. Of note:

- the rule is global, not project specific. I have tried also to set a rule on a specific project, it didn't seem to make a difference.

- my trigger is different: i put it as 'when value changes for sprint', you put it as 'when sprint started'. my ideal is that when the sprint value is changed on a ticket (create/edit... i left it as 'all operations'), whether the sprint is started or not, the fix version is updated. maybe that is not feasible, given the trigger and the action are on the same ticket? 

- related to the above, the change is to be applied 'to current issue', rather than 'to issues in the sprint'. i tried 'for issues in the sprint' and that generates an error.

- i added 'add fix value from current issue'. i tired 'from trigger issue', as i am confused which is which when it is the same issue, but that didn't make any difference.

What happens:

- create {{sprint.name}} does create a new version, available in the list of versions. If the same version already exists, it doesn't create a new one

- the version is not assigned to the issue whose sprint has just changed, the version field stays blank, albeit with new options available if indeed a new name was created.

[Bill Sheboy]

Hi @l bascle 

The reason I chose the trigger "Sprint Started' is that I wonder if the sprint value is a placeholder *before* the sprint starts, and so copying it before that point may not be valid.  This is why when you tried to access issues in the sprint, it did not work.

Another benefit of using the "Sprint Started" trigger is that the rule only runs when needed, rather than churning if issues are added/removed from the sprint.

As for creating the new version, if one with the same name exists *and* is unreleased, you cannot create a new one within the same project.

Please note that all the testing I did was at a project-level, not global.  My company didn't buy additional licensing for the extra global rule executions.

[John Funk]

Hi @l bascle ,

I don't think you are going to be able to use automation to populate the release if the value of the release does not exist already. If it does, then you can certainly copy the value into that field. But it can't Create the release on the fly. 

[l bascle]

Thanks John. So do you think creating placeholders in releases would do the trick then? If so, what is even the basic workflow, because all I could seen in terms of triggers came from the change of status. 

[John Funk]

If you know what your releases are going to look like as far as naming, I would go ahead and create those in your project. Then you just need to make sure you use those same exact value for the Sprint. 

So your rule would be based on a Field value changed on the Sprint field. 

Then you would do a new Action for Edit Issue and copy the value from the Current Issue. 

Click on the word Current Issue then and select the Sprint field to copy from.