If all issues are done for that release & release date is passed,can we mark Fix Version as released

[Mohini Chandwani]

Can we develop Jira automation rule which checks if all issues are done for that release & release date is passed. If both conditions are met, fix version should be marked as released.

Actually I have developed the rule but it does not consider all the issues. It checks one at a time like status is done and release date is passed, it will mark that fix version as released but that fix version is having other issues which are not in done status.

Can refer the below snap.

[Anastasiia Tsvetkova]

Hello, @Bill Sheboy 

Sorry to bother you, Bt have a question about the steps that you provided above. 

I did it for my project and for some reason it doesn't trigger. Could you please help me figure out why.

I'm newby for JIRA automation, please correct me if I'm wrong somewhere...

The task was -> once all issues in the Release has status Live then release this version otherwise wait until all of them are Live (coz we have different Repo and issues included in 1 release)

Audit log has nothing it seems event hasn't been triggered...

[Bill Sheboy]

Hi @Anastasiia Tsvetkova -- Welcome to the Atlassian Community!

First thing, the original post was quite a while ago.  And so I recommend creating a new question and linking back to this one.  Otherwise only the people following this thread will see it, and that may include people who no longer monitor the community.  

Next, please post an image of your audit log details showing the rule execution.  That will allow comparison of the symptom you are seeing to the rule steps.

Back to your question: there are a couple of things I notice...

The second JQL condition you have on {{lookupIssues.size}} = 0 is incorrect; that instead needs to be an advanced compare condition:

• first value: {{lookupIssues.size|0}}
• condition: equals
• second value: 0

Next, your trigger references transitions from Awaiting Release to Live.  Is that the case for all issues or could some move to Live from another status?  If so, the rule would not trigger.

Kind regards,
Bill

[Anastasiia Tsvetkova]

Thank you @Bill Sheboy for your reply.

Will take in mind your comments.

1. The thing is when I was expecting that the rule will be triggered it did nothing and Audit log showed nothing after my changes 

2. The error shows exact error that you mentioned about my JQL... will adjust it 

3. Trying to make releases only from Awaiting release statuses. Mostly releases for heaps of issues/tickets. 

4. Could you please elaborate more why we need 0 in {{lookupIssues.size|0}}

Thank you for support

Regards,

Anastasiia

[Bill Sheboy]

Hi @Mohini Chandwani 

To do what you ask, you could use Lookup Issues actions and JQL to check the count of issues in particular conditions, and then release the version when satisfied.  For example:

• Trigger: scheduled (no JQL needed)
• Action: lookup issues on JQL for fixversion = earliestUnreleasedVersion()  ...which gets all issues in the next release
• Condition: check the version date of the first issue in the lookup is past (or today if you want)  {{lookupIssues.first.fixVersion.releaseDate}}
• Action: lookup issues on JQL for fixversion = earliestUnreleasedVersion() AND status NOT IN (Closed, Done) ...or whatever your final status values are
• Condition: check the count is zero  {{lookupIssues.size}}  ...to confirm no open issues remain for the release
• Action: Release version ...which should release the earliest unreleased version

Best regards,

Bill

[Mohini Chandwani]

Hello @Bill Sheboy ,

I am using Server version so lookup issue component is not available.

And for trigger part using scheduled but it requires JQL because if I choose simply run the conditions and actions without providing issues option it gives the following error.

Is there any way using webhook data or any other approach to do this?

[Bill Sheboy]

Hi @Mohini Chandwani 

Sorry, I did not catch that you were on the server version when I answered.

Yes, you could use a web request such as to call the REST API for some JQL to replace what lookup issues could provide.  Here is an article on using that technique:

https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828

As another alternative, you could also use a branch to update some indicator entity properties in the version.  Then check those to decide if the version should be released.