fix: Re-enable CI checks on release branches

[michael-s-molina]

SUMMARY

#26766 restricted some CI workflows to run specifically on the master branch. This resulted in a problem for the release branches where running CI is really important when cherry-picking fixes into the branch. This PR adds a regex to allow CI to run on push events for release branches, restoring the previous behavior.

Check filter-pattern-cheat-sheet for details about the regex. Dots don't need to be escaped.

TESTING INSTRUCTIONS

Restricted CI workflows should run only on master and branches that match the regex.

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.34%. Comparing base (d2f7dec) to head (24efa91).

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #27390   +/-   ##
=======================================
  Coverage   67.34%   67.34%           
=======================================
  Files        1909     1909           
  Lines       74592    74592           
  Branches     8320     8320           
=======================================
  Hits        50235    50235           
  Misses      22305    22305           
  Partials     2052     2052           

Flag	Coverage Δ
mysql	77.98% <ø> (ø)
postgres	78.08% <ø> (ø)
python	78.22% <ø> (ø)
sqlite	77.60% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rusackas]

Maybe the precommit hook isn't checking these files? The change in quotes seems unusual if so.

[mistercrunch]

Oh I didn't think of release branches when I made the changes, but seems totally reasonable that we'd run CI for release branches.

I had to review the concurrency setting, and currently it will run CI for every "push", which I believe is desired behavior (@michael-s-molina please confirm). Note that the way it's set up + GHA mechanics, it will run CI for each push (not for each commit) and won't kill previous jobs the same way that we do on pull_request event, where a new push will kill previously running jobs. If you wanted to get CI to run for each cherry you pick you can do so by pushing after each cherry to get a CI run for each one.

Total side note here, I'd love to keep things more DRY across actions (not repeating the branch name pattern for instance, or the concurrency setting), but I don't think we're at the critical mass of complexity to justify something more dynamic just yet. It could be nice to have some sort of DSL that generates the actions more dynamically, but seems over-engineered for where we're at currently.

[mistercrunch]

@rusackas I think the check-yaml pre-commit hook isn't sophisticated/opinionated like that, it just makes sure the yaml is valid, it doesn't care about how it's styled