nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Dan Driscoll_wylrpx

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?

Accepted answers

Derek Fields _RightStar_

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

All comments

Derek Fields _RightStar_

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_wylrpx

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_wylrpx

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)

Condition

contains regular expression

Regular expression

(main|releases)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud