ci: cancel a PR run the next push has already replaced

[fujibee]

CI only. One file, .github/workflows/tests.yml, and nothing a user installs or runs changes.

A superseded run keeps its macOS jobs queued, and those are the scarce ones.

The measurements below are a historical baseline

Taken 2026-08-19, over the runs of this workflow that existed at that point — before #885 raised the shard timeout from 25 to 30 minutes and moved the heavy files between shards. The queue figures have not been re-measured since.

They are kept because they are what motivated this change, and because the mechanism they describe is untouched by #885: a run still asks for four macOS jobs, and a superseded run still holds them until it is cancelled.

macOS   median 18.6 min   max 167.1 min   over 20 min in 19 of 40 runs
ubuntu  median  0.3 min   max  32.5 min   over 20 min in  1 of 40 runs

The wait arrived in bursts:

thirteen runs created in one two-hour window   every one waited 20-167 min
the other twenty-seven runs                    median 9.3 min

And what makes the burst is that nothing stops a superseded run:

PR-branch runs examined            92
already overtaken by a later push  65  (71%)

Each of those 65 was still holding four macOS runner slots for a commit whose result nobody would read. One branch produced fifteen runs; fourteen were obsolete on arrival, which is fifty-six macOS jobs spent on stale answers.

Structural, and unchanged by #885: the 71% superseded rate and the four macOS jobs per run. Those follow from how branches are pushed and how the matrix is shaped, not from the timeout.

The change

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

Keyed on the PR number, so a push cancels the run for the commit it replaced and nothing else. Pushes to main fall back to the SHA, which gives each its own group: never cancelled, because cancel-in-progress is false off the pull_request event, and never serialised behind one another either — which a shared group would have done, and which would be a worse failure than the one being fixed.

What this does not do

It does not make a single run faster. A run nobody supersedes waits exactly as long as before. What it removes is the demand a superseded run keeps making.

Not measured

Queue times after #885. The timeout change and the shard re-placement both affect how long a macOS job occupies a runner, so the figures above should be read as the state that prompted this, not as the state today.