Build/Test Tools: Cancel old CI runs when a newer commit is pushed

[lancewillett]

Pushing a new commit to a branch starts a fresh CI run but doesn't stop the older one. Both run to completion, so the runner keeps testing a commit no one is waiting on. On busy branches this wastes a meaningful amount of runner time.

The concurrency group already cancels superseded runs for pull requests, but for push events it falls back to the commit SHA, so every push gets its own group and nothing is ever cancelled. The inline comment says the fallback was meant to cancel "any other events," so today's behavior doesn't match the intent.

Fix: group push runs by branch, so a newer push cancels the still-running older run on the same branch. Scheduled runs (the weekly full-matrix run) and manual runs get a unique group and are never cancelled.

Starting with one workflow as a pilot: coding-standards.yml. Once confirmed, the same one-line change applies to the other push-triggered workflows.

Pushing a new commit to a branch starts a fresh CI run but doesn't stop the
old one. Both run to the end, so the runner keeps testing a commit no one is
waiting on.

This changes the concurrency group so a new push cancels the still-running
older run on the same branch. Pull request runs already work this way; this
extends it to pushes.

Scheduled runs (the weekly full-matrix run) and manual runs are left alone—they
get their own group and are never cancelled.

This is a pilot on one workflow. If it behaves as expected, the same change
applies to the other push-triggered workflows.

Use of AI Tools: Claude Code—used to draft the change and description.

[peterwilsoncc]

For production branches, I think it's best to allow the checks to continue running.

Cancelling the runs would make it difficult to determine which commit caused the tests to start failing in periods of high activity.

Beyond what Adi said, I think this change could have the opposite of the intended effect. If the phpunit workflow takes ~18 minutes to run, commits less than 18 minutes apart would prevent the status being reported due to the cancellation. In the leadup to code freeze when there's a flurry of commits in quick succession, this might fully prevent any status being reported for an hour or more.

Closing this based on good feedback from John and Adi.

Thanks both. The runner savings we are chasing are better won by trimming the PHPUnit matrix (fewer jobs per run, every commit still fully reported).