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

[Dan Driscoll]

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?  

[Derek Fields _RightStar_ · Accepted solution]

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]

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]

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]

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]

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]

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!