When issues moved to Live then Release a version

[Anastasiia Tsvetkova]

Hello, guys. I need help to figure out how to set up this properly... I'm not an expert and found it somewhere within this community.

So the problem is we have issues included in a release from different repos. And one repo might be deployed earlier than another.

I want to wait until ALL issues are in LIVE status (for this I have another automation rule) and only then Release this version.

Now it looks like something triggers to release a version 

Unfortunately, I don't have the whole audit log as there were a bunch of tickets within one release.

[Kalyan Sattaluri]

Apologies if I am missing, below steps should work? Please correct unless I misstated your requirement:

• Schedule rule with no JQL and run daily 
• lookup issues with your JQL -> fixversion = earliestUnreleasedVersion() AND status NOT IN (Live)
• Using advacnced compare, check if size is = 0  --> {lookupissues.size}} equals 0
• If so, then release version..

[Bill Sheboy]

Hi @Anastasiia Tsvetkova 

To try to help with your scenario, would you please answer these questions:

1) How many versions does your team have unreleased when this rule is running: just one for the next release, or future ones also?

2) Does anyone on the team ever manually release a version?

3) Are there any other rules which could be creating, updating, or releasing versions?

4) What is in your rule's JQL condition?  That is, what is it testing, and so why are 2 lookup issue actions needed?

5) Have you tried adding a write to the audit log before the attempt to release the version to show the version the rule expects to release?

While answering those questions, I recommend looking at the audit log, opening execution's details, and looking for the one that performed the release.

Kind regards,
Bill

[Anastasiia Tsvetkova]

Hey, @Bill Sheboy thank you for your help.

1. Usually we do one version by one. One released - another created etc.

2. I'm the only one who is responsible for releases. So, I have to manually release them when I see that it was unreleased or released, but not quite right... not sure what is wrong there (coz I have another automation rule that waits till the version is released and creates another one)

3. So, the first one is for:

- looking for all issues that are included in the UnreleasedVersion -> fixversion = earliestUnreleasedVersion()

- then for all these issues ->

- looking for every issue that has NOT been moved Live -> fixversion = earliestUnreleasedVersion() AND status NOT IN (Live)

     - coz we have different repos some tickets might be released later than others.... So I need to wait for EVERY ticket to be moved to LIVE

- if it cannot find issues not in LIVE

- then Release this version....

4. Do you mean this guy? Before the release version -> Add value to the audit log ->  {{version.name}} ? Will do, let's see what it shows

5. Successful audit -> Found the case when within the ONE release, for some reason version was released even though there was another issue moved to LIVE after

Thank you. 

[Bill Sheboy]

Do your releases ever contain more than 100 issues?  If so, automation rule triggers / actions / branches are limited to 100 items, and so the ones beyond that limit could be causing this symptom.

Based on your answer to question #3 about other rules, you seem to be saying this is the only automation rule doing anything with releases.

Following up on question # 4, your rule has a JQL condition as its third step.  Please post an image showing the details of that condition.  And, please explain what that condition is meant to test.  Thanks!

[Anastasiia Tsvetkova]

The most heave one was with 67 issues, should not be a problem though. But good to know about the limit. 

3. I have some others

- When the Version is released send a notification to Slack

- After the current version is released create a new one

4. 

So, the first one is for:

- looking for all issues that are included in the UnreleasedVersion -> fixversion = earliestUnreleasedVersion()

- then for all these issues ->

- looking for every issue that has NOT been moved Live -> fixversion = earliestUnreleasedVersion() AND status NOT IN (Live)

     - coz we have different repos some tickets might be released later than others.... So I need to wait for EVERY ticket to be moved to LIVE

- if it cannot find issues not in LIVE

- then Release this version....

[Bill Sheboy]

That JQL condition appears to have a problem, as it needs to be valid JQL and instead it just has a smart value with a date.

What are you trying to test with that one?

[Anastasiia Tsvetkova]

Trying to find all issues that belongs to this release version ->

Then....check what is not LIVE etc.

Do you think I don't need this step as I have pretty much the same in a previous one?

[Bill Sheboy]

Correct, I do not believe you need that step unless...there is a possibility of there being no issues in a release.

If that is possible, what would you want the rule to do: still release the version, archive it, or nothing.

If a release will always have issues, your rule can be simplified, dropping the first lookup issues and the JQL condition:

• trigger: on the issue transition
• action: lookup issues with JQL for issues in the next unreleased version and not in Live status
• advanced compare condition: check the count is 0
• action: release the version

[Bill Sheboy]

Hi @Anastasiia Tsvetkova 

I am following up to learn if your question has been solved.  If so, please consider marking this one as "answered" to help others find solutions faster.  If not, let us know what additional help you need.

Thanks!

[Anastasiia Tsvetkova]

Hi, @Bill Sheboy not really =( 

Today as an example an Automation rule hasn't triggered at all. I see in the Audit log data for previous releases but not for today's one

[Bill Sheboy]

Hi, @Anastasiia Tsvetkova 

I am looking back over your rule, and the information in the JQL Condition does not look valid.  It seems to only have a reference to {{lookupIssues.first.fixVersion.releaseDate}} and that by itself is not valid JQL.  What was that JQL meant to test?

Thanks!

[Anastasiia Tsvetkova]

Hi, @Bill Sheboy 

Since then I updated the Automation, and now it looks like this. But it seems something is off... 

[Bill Sheboy]

Please post an image showing the audit log with the details expanded (Show more) so we can see which steps did / did not run.  Thanks!

[Anastasiia Tsvetkova]

That is the thing, it hasn't triggered at all... I see all of my previous ones, and cannot get why this one didn't fire up... (In the Audit log there are no details about this event.... which is strange. )

What might be the coz?

And we had another release yesterday. For this one an automation rule triggered. 

[Bill Sheboy]

That rule uses a trigger of issue transitioned, from Awaiting Release to Live.

How did the transition occur: did a person do it or did another rule perform the transition.