Version creation seems to try to create the same version twice

[Natalia Bakos]

Hi,

I'm writing an automation which triggers an automated version creation and release. The trigger is coming from a webhook.

As you can see it creates a version then it releases it. The "If" part is not necessary, since I can't use smart values in the project setup, I added this to make sure that the release will be created in the correct project.

The "Create version" step behaves very strangely.

1. When I leave the project in the "Create version" step as "Same project" it creates 2 releases for me, one unreleased without any issues connected to it and one released one (after the "Release version" step) with the proper issues connected to it. It's annoying.

2. When I selected the specific project in the "Create version" step it creates only one version with the correct released state and issued connected to it, but in the audit logs I can see an error while everything created properly:

Create version

Successfully created version .

xxxxxxxx - v1.2.1

Failed to create version .

A version with this name already exists in this project. (name)

Why?

Thank you for the help,

Natalia

[Bill Sheboy]

Hi @Natalia Bakos 

Your trigger has selected the option, "Issues provided in the webhook HTTP POST body."  And so I believe the rule loops to run the steps over each issue, including repeatedly creating the version and trying to release it.  Based on timing, that may or may not fail when it collides on the version create / release.

One alternative is to:

• select the incoming webhook trigger option of "No issues from the webhook",
• pass the issue keys in custom data for the request as CSV in the source process, and
• iterate over them with a single branch on JQL. 

For example, the incoming data might look like this:

{ "data": { "key": "ENG-4285,ENG-4270" } }

And so the branch JQL could be:

key IN ( {{webhookData.key}} )

Kind regards,
Bill

[Natalia Bakos]

Thank you for the reply. I'll modify my scripts accordingly. 

Though, it still strange that if I'm choosing the "Same project" when I'm creating the version at the end I have 2 versions with the same name, one released and one unreleased.

[Bill Sheboy]

Yup; that symptom may be coincidental (i.e., a racetrack timing error) or a different default value in the REST API when the project is / is not specifically selected in the rule action.  And so:

• one of the loop passes creates and releases a version ,
• a later one tries to creates with the same name as an unreleased one (and fails due to collision),
• another tries to release by name but finds none unreleased (failing silently),
• etc.

That is because the rule uses the version name attribute (and not the id) in the actions.  If the id was always used in the release I hypothesize there could be one released version for each one in the trigger...or more consistent errors in the log.

[Natalia Bakos]

Hmmm, if this is how it works, then it would be really-really helpful if a smart value can be used to select the project when creating/releasing a version. In this current setup the version creation/release can't be generalized, I have to select a specific project, since I can't use the issue's settings.

But, I managed to create a working automation considering the info you gave.

Here's my solution to anyone who is struggling with the same thing.

Thank you for your explanation!

[Bill Sheboy]

Well done!

Regarding your comment about generalizing this solution (such as for a global-scope automation rule), the automation Create Version action would not help because it needs some context to select the target project: either rule scope or the issue data.

A possible workaround would be to use Lookup Issues with JQL to get one of the issues (from the webhook data), and then use the Send Web Request action to call the Jira REST API endpoint to create and release the version for the specific project.  If you want more information about trying that approach, please let me know.