Jira Automation - complex if statement doesn't work

[Tuur Lievens (TME)]

Hello!

I have been trying to get an automation working for weeks now (only runs on production deploy, so there's no way to test quicker) and am stuck on what the issue could be, I suspect it has something to do with the JQL string matcher "~" on a smart value.

The main culprit is the highlighted if statement in this screenshot:

...

A ticket that went throught this flow ended like so: 

Some more context on why this rule is build this way:

• This rule will trigger on a github deployment
• Our project contains tickets with multiple (3) different deploy environments, 2 of which have multiple "brands" (prod_aem_* and prod_aph_*). Tickets are assigned a related component "NC - Build" and "NC - Apheleia"
• Our board workflow follows a standard set by the company which we cannot change for all sorts of reasons. This means we sometimes have to skip a few ticket status, but it depends on the ticke
• If I make nested if statements to combine both of these facts (env and component are linked + multiple transition actions), the resulting rule is overly complex, so instead I wanted to merge the env-component rule to a single if statement that can be easily copy-pasted

Does anybody have any idea how to fix this if statement?

[Bill Sheboy · Accepted solution]

Hi @Tuur Lievens (TME) -- Welcome to the Atlassian Community!

Would you please post your complete rule in a single image, perhaps using a scrolling page capture?  That will help see the overall context to help explain what is happening.

Until we see that...

Perhaps add some additional writes to the audit log to confirm the values your conditions are testing.  That will help to compare to your conditions.

Next, the CONTAINS ~ operator is defined for JQL although I wonder how it works (or not) with smart values like {{deployment}} and its attributes which only exist when the rule is running after those deploy triggers.  I recommend testing by using text functions to extract the values needed, or use conditional smart value logic.

For example, use left(), substringBefore(), or match() to extract (within conditional logic), saving those to created variables before the first rule conditions, and then use those variables in smart value conditions.

Kind regards,
Bill

[Tuur Lievens (TME)]

Hi Bill

Thanks for taking a crack at the issue so quickly!
I'll give that startsWith function a try.

I also didn't know you could create variables, that might help me simplify the setting as well.

Here's the full screenshot, brace yourself...

[Bill Sheboy]

Thanks, and...

The automation audit log is not super helpful regarding conditions, particularly with such a complex rule.  And the ability to nest if / else blocks is a very new feature, so perhaps this one is pushing it to the limits.  By my count, there are 10 paths through it, and the log you show does not seem to match up with rule flow (or I just miscounted).

To help know what is happening, I recommend:

• Adding a write to the log after each condition with a unique identifier to confirm the rule progress
• And if that shows the rule is not executing as the data should indicate, use the text functions I noted earlier in order to extract / test the values to workaround challenges with the CONTAINS ~ operator.  This could help manage another possibility...
  • Some smart values in rules are dynamic, loaded with data just-in-time
  • And some rule components have known race-track issues, leading to possible problems with the order of evaluation
  • I do not know if {{deployment}} one fits that case, but if it does extracting to variables first forces full evaluation before any conditions are used

[Tuur Lievens (TME)]

Hi @Bill Sheboy 

My apolagies for the late answer, like I said, I only have the ability to test every few weeks due to this being linked with a deploy. 

I was able to simplify the logic a lot with the help of the "create variable function" you mentioned. Due to that it was also feasible to move away from the JQL statements.

This is what I ended up with, however, as marked in red, the "create variable" action does not seem to work? The value is empty, I tried with both "yes/no" and "true/false", currently waiting for results with "1/0".

[Bill Sheboy]

That symptom is likely a scoping issue, and can be solved by first creating the variable before the first condition.  Then when it is re-created inside, the value will be replaced and available later in the rule.

For example:

• trigger: some trigger
• action: create variable, to set a default value and anchor scoping
  • name: varContinue
  • smart value: yes
• if / else condition: 
  • ...
  • action: create variable
    • name: varContinue
    • smart value: no
  • ...
• else / if condition:
  • ...
• advanced compare condition:
  • something that tests {{varContinue}}

Also with this technique, you may be able to simplify the logic to only set the value when it differs from the default value of the variable.

[Tuur Lievens (TME)]

Hi @Bill Sheboy 

Creating the variable before the if/else statement fixed the issue. We just had another release and the workflow is now working as expected.

Thanks for your help!

[Bill Sheboy]

Awesome; I am glad to learn that helped!

Thanks for following up as this will help others reviewing this thread in the future confirm the behavior.