Webhook response in Jira automation

[Gilad Waldman]

After creating an automation that gets latest released version number, merges all minor jira releases into a major and releasing the major version, i left with the minor versions unreleased and with no tickets in.

So am looking for a way to auto delete these minor versions. Reading in the community, i noticed the best workaround is with REST API via webhook -  get all versions and then run over the results, extract the version i need by name and get their id for another rest api delete step. Anyone has better approch? 

Thank you.

[Bill Sheboy · Accepted solution]

Hi @Gilad Waldman 

First thing: how is your team using the "minor version" releases?  That is, are they:

1. just holding buckets, and never intended to be Jira-released as versions or to production code,
2. they were incrementally released to production code but the version was not Jira-released,
3. something else?

Considering these may give you other ideas how to use the "minor versions".

For now, let's assume it is #1 and they are just holding buckets in Jira and not for release.  In that case, calling the REST API with the Send Web Request action would be needed as there is no "delete version" rule action.

The REST API endpoint to Delete Version has been deprecated, and replaced with Delete and Replace Version.  With that one, your rule could combine the operations by:

• identify each "minor version" for a releasable, "major version"
• branch over, and call the endpoint once for each "minor version" to update them to the major and delete the minor

Here is a how-to article for calling a REST API endpoint from a rule: https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828

And here is the new Delete and Replace Version endpoint: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-project-versions/#api-rest-api-3-version-id-removeandswap-post

And here is a how-to article to determine the correct custom field ids needed for the above call: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Kind regards,
Bill

[Gilad Waldman]

Thanks for the detailed response @Bill Sheboy 

We use minors similiar to option 2 - we constantly push new code but we release a version out only on specific times. at that point we merge all version into one last version under the same branch. 

The above (3rd link) helped me to get the version id i needed to replace, but now i also need to mention the version i want the tickets to move to, and i only have the version name and not the version id. 

I get this version from a text message and i dont have any issue i can search on to identify the new major version id.

Any idea on that?

[Bill Sheboy]

Thanks for that information.  Just to confirm, you only want the Jira issues to have the major version value for the release (in Jira and to prod), correct?

If so, if you have the Jira issues, you could get the minor version name or id from their Fix Versions values.  Assuming there is one-and-only-one value in the Fix Versions field, that would be {{issue.fixVersions.first.name}} and {{issue.fixVersions.first.id}}  When you have a list of issues, you could use distinct to get each one from the set.

If you do not have the Jira issues, you could use the name to call the REST API endpoint and pass the name to query for them within the specific project: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-project-versions/#api-rest-api-3-project-projectidorkey-version-get

[Gilad Waldman]

That worked! Thanks.. 

Now I believe I'm really close - just trying to run on every ticket that has the minor version and for each one run webhook to Jira REST API. 

As i'm using branch on JQL I'm getting all the values with a comma and im not sure how can i run for each one seperatly? 

This is the output of my branch JQL : IL-51101, IL-52284

And obviously this cannot be used on the following webrequest url

And this is the flow

[Bill Sheboy]

My understanding is the new endpoint to "Delete and Replace Version" automagically finds and updates the issues and so no branching over issues is needed.  Instead identify each minor version to replace and use that in the call with branching.

To do that, the rule could use JQL to find the issues and load them with the Lookup Issues action: https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Lookup-issues

Assuming that each issue was only added to one minor version, this will produce the list of minor version id values that can be iterated using an Advanced Branch:

{{lookupIssues.fixVersions.id.join(",").remove("[").remove("]").remove(" ").split(",").distinct}}

How that expression works is:

• use inline iteration over the lookup issue results' Fix Versions where each one is a list
• get the id values, and join the arrays together with commas  This would be a list-of-lists represented as text.  For example: [10001], [10031], [10038]
• remove the brackets from the nested lists
• remove any leftover spaces
• split the results back into a list again
• grab the distinct values so there is only one copy of each version's id

[Gilad Waldman]

You absoultly right...Took the advise and made modifications to just find the relvant versions (and not running on all tickets), then removed the "major version" id from that list and used the advanced branching to run the lookup.

THANK YOU!!

[Bill Sheboy]

Awesome; I am glad to learn that helped!

[Gilad Waldman]

Resurfesing this one as I've just started to get errors on this automations - 'Error 500'

Error looks random as im running the RemoveAndSwap webhook on a few versions (From the branch) and the error is only on a few.

@Bill Sheboy  Any idea what is the error root cause? This sounds like a server issue but is there anything i can do?

[Bill Sheboy]

Hi @Gilad Waldman 

Is the rule still branching over the distinct versions, and so each one is only attempting the REST API call one time (avoiding any racetrack conditions)?

If so, you may want to ping the Atlassian Support team so they can check the internal logging for anything they see: https://support.atlassian.com/contact/#/

If instead the rule is branching over issues (not versions) it could be colliding by attempting to replace / remove versions which no longer exists at the same time the issue is already being updated by the endpoint (due to another issue's processing).

Kind regards,
Bill

[Gilad Waldman]

Thanks @Bill Sheboy , branch is on versions. i will contact them and will get back with the finding. 

thank you.