nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

Bill Sheboy

Hi @Gilad Waldman

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

just holding buckets, and never intended to be Jira-released as versions or to production code,
they were incrementally released to production code but the version was not Jira-released,
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

All comments

Bill Sheboy

Hi @Gilad Waldman

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

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

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

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

Screenshot 2024-12-29 103205.png

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud