Is there a way I can check if all the Jira items for a release version are closed thru JQL?

[Imran_Ali]

I am trying to create a condition for triggering my new Automation action for Releasing the Versions for a particular month. I used this JQL in my condition: Project = nimbus and issuetype in (Story, Defect, Task, Epic) and status in (Closed, "Ready For Release", Done, Abandoned, Cancelled, Committed, Resolved) and "Release date (Fix)" >= "2022-09-01" and "Release date (Fix)" <= "2022-09-30". 

But this doesn't tell me if any Jira items are still active in that release period. How do I know if all the Jira items for a Fix Version are closed thru JQL? Is there anything else I can use If its not feasible thru JQL. Once I know this than I can put this as a Trigger condition for triggering my 'Release Version' automatically.

[Bill Sheboy · Accepted solution]

Hi @Imran_Ali -- Welcome to the Atlassian Community!

I am a bit confused by your use of terminology, so first thing...

• a Trigger is a component of automation rules which fires based on some event.  For example, Version Released
• a Condition is a decision point in a rule.  For example, when a field value has a specific value
• an Action does something, such as, "Release Version"

It seems you want a rule, "triggered" on something, which then uses a Condition to decide when to call the Action, "Release Version". Please let me know if I am misunderstanding that you are asking.

On to your question: what have you tried thus far?  If you have a rule, please post an image of your rule and of the audit log to show the details of execution.  That will provide context for the community to offer ideas.

If you do not have a rule yet...

For your JQL to detect the readiness to release, perhaps this would work to detect there are any issues assigned which are not in a "done" status category and in the earliest unreleased version:

project = nimbus AND issueType IN (Story, Defect, Task, Epic) AND fixversion = earliestUnreleasedVersion() AND statusCategory != Done

You could use that with the Lookup Issues action (or condition with JQL) to determine if there are any open issues.  If there are none, proceed with releasing the version.

Kind regards,
Bill

[Imran_Ali]

Hi @Bill Sheboy , Thanks for details. I am sure this would help me. Will get back if I come across any issues. 

Appreciate the response!

[Imran_Ali]

I am coming across the following 2 issues now after going further with this JQL: project = nimbus AND issueType IN (Story, Defect, Task, Epic) AND fixversion = earliestUnreleasedVersion() AND statusCategory = Done

1. “StatusCategory = done” --> If the version is having (for example) 2 Jira issues with 1 in Done category (closed status) and other in Not Done (Open/In-progress.. status) then also this JQL is marking that Release Version as RELEASED. This is incorrect. It should mark as released if all its issues are in DONE statusCategory.

Is there a way I can get to know if all the issues for the earliestUnreleasedVersion() or any version from unreleasedVersions() function are in Done statusCategory?

2. If I have 2 unreleased versions as below - earliestUnreleasedVersion() is always checking for the ‘Def’ version. But I want the ‘Abc’ version to be Automatically Released as all its issues are in Done StatusCategory. And this is the earliest unreleased version having all its items in Done category. At the same time I don’t want to delete the ‘Def’ version for some reason. So what modification I can do in my JQL so that it would identify ‘Abc’ version which is good to be Released?

Version name	Start-date (mm-dd-yyyy)	Release-date (mm-dd-yyyy)	Number of issues	Status info
Abc	10-01-2022	10-15-2022	3	All Done
Def	09-01-2022	09-15-2022	--Nil--	_

[Bill Sheboy]

Hi!

For your first question, I was suggesting to test for ...statusCategory != Done in order to find any incomplete issues.  Let's say you used Lookup Issues to gather them with the the JQL, then the advanced compare condition would be like this:

• ...
• action: lookup issues with the JQL
• advanced compare condition
  • first value: {{lookupIssues.size|0}}
  • condition: equals
  • second value: 0
• ...proceed to release the version

Your second question about version ordering is tougher to solve...The order of the versions on the releases page determines what is "next", with the last one in the list as "next".  So that query would always find "Def" in your list.

You options to help are:

• reorder the version list,
• lookup the version by its specific name (e.g. Abc) rather than using the function earliestUnreleasedVersion
• find a way to dynamically identify the correct version.  This often requires either a specific naming convention for versions (based on some issue fields or date/time) or to call and query all possible versions from the REST API

[Imran_Ali]

No, its not working. I tried as below. It seems the Action "Release version" always looks at the next unreleased version which is GHI in below example. There are many unreleased versions (with not all of their items in Done status) prior to a good unreleased version (ABC) which is having all its items in Done status category.

ABC - Unreleased - All done

DEF - Unreleased - 1 inprogress

GHI - Unreleased - 1 done, 2 inprogress

I can't find any action which can reach me to a good candidate of any unreleased Version. And I don't want to hardcode anything in the 'Release version' action also because we don't want to edit the rule once it is published. 

Please let me know if I am missing anything. It would be good, If we have some kind of intelligent function which can sense this need what users are expecting.

If: all match

• project = nimbus AND issuetype IN (Story, Defect, Task, Epic) AND fixversion in UnreleasedVersions() AND statusCategory! = Done
• {{lookupissues.size | 0}} equals 0

Then: Release version

           Next unreleased

[Bill Sheboy]

Jira defines the "next" version is the one at the bottom of the list on the releases page.  When you want a different version to be "next", you drag it to the bottom of the list.  There is no other built-in way to select "next".

If you have other criteria that defines "next release candidate" (e.g. a naming convention), you would instead need to find the version by calling the REST API to gather the versions, identify your match, and then perform the query for open issues.

[Imran_Ali]

Hi @Bill Sheboy , I don't want to change the order of the versions if the good candidate not showing as next. This would require the project Admins to track thru those versions if they are not released.

I will tryout the other thing which you mentioned and see if I get thru. Thanks!