Global Automation: Are rules mutually exclusive or can multiple ones execute for same event?

Dan Driscoll March 15, 2024

I have several rules that trigger on the DevOp "Build Failure" event, and each notifies different webhooks.

One is for "any" build failure

One is for build failure against certain branch names (main|releases) and I'm not exactly certain on the syntax of the list of names.   I changed it recently from a "Contains" to  a "Contains regular expression" based on something I read somewhere on the web.  

There are a couple of additional rules as well, overlapping on the conditionals.  

My question is do they all fire and execute?  Or after a first one executes, does automation bail out on the others?  

1 answer

1 accepted

2 votes
Answer accepted
C_ Derek Fields
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 15, 2024

All automations that are associated with the trigger will execute. If you don't want all of them to execute, combine them into a single automation with different if/else blocks

 

Dan Driscoll March 15, 2024

Thank you!  I am definitely considering that after I understand more about "or"ing conditionals and/or the "else if" clause.    For now I want to keep them distributed to understand explicitly which types of failures are occurring.   Plenty of room against my monthly limit for now.  but good idea to combine later. 

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 16, 2024

Hi @Dan Driscoll 

Yes, and...to the suggestion about possibly combining the rules and using if / else condition blocks...

After the changes to the automation limits / packaging, project-scope rules no long have unlimited usage executions.  You appear to be using a standard license, and so combining the rules will help manage your usage.  Please look here to learn more:

https://www.atlassian.com/blog/announcements/cloud-automation-packaging-update
https://support.atlassian.com/cloud-automation/docs/automation-service-limits/

Some other advantages of combining the rules are:

  • reducing risk of maintenance errors, where something common to the rules is only changed in one place
  • preventing collisions / timing problems if there are any common issues / items updated by different rules

Kind regards,
Bill

Dan Driscoll March 18, 2024

Thank you Bill. Sage advice.  I've disabled the Build Success event automations as those were mostly white noise, and believe this will keep us well under the monthly limit for now.  Continuing to root cause why Build Failure events against our "main" and "releases" branches are not resulting in automation notifications to my Teams channels.   OTOH my new "Any" Build Failure would pick them up so next time one fails, or I convince a developer to fail one intentionally, well I'll have confirmation. 

While I have you here, can you confirm this is correct syntax for such a branch name comparison?  (attempting to paste or attach a graphic...) 

First value* (required)

{{branch.name}}

 

Condition

contains regular expression

 

Regular expression

(main|releases)

 

 

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 18, 2024

The syntax looks correct (without testing it myself), and I recommend adding a write to the audit log for {{branch.name}} before the condition and confirming it contains what you expect.

Dan Driscoll March 20, 2024

I notice {{branch.name}} is indeed not showing up over in my MS Teams notifications for the rule that fires and notifies on any Build Failure.   That's the likely root cause as you point out, and I'll follow up with the GitHub configurators. 

btw, how does one "write to the audit log" from within a Jira rules definition?  Is there an explicit THEN action for that, or some other technique? 

Never mind - I just found the "Log action" component.  Thanks!

Like Bill Sheboy likes this

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS
AUG Leaders

Atlassian Community Events