GeezerVison

Problem

npm-compatibility.yml, pnpm-compatibility.yml and pipenv-compatibility.yml are the only PR-triggered compatibility workflows with no concurrency group. ci.yml, bun, vlt, go, composer, gradle, pdm, poetry and bench all have one. So when a PR gets a new push, the old run of these three keeps going: npm has 11 jobs (build + 10 npm legs), pnpm has 26, Pipenv 6+. They all run against a commit that will never merge.

I looked at the last 100 pull_request runs of each workflow (2026-10-05, about 11:30–20:35 UTC), counting runs where a newer run on the same branch started before the old one finished:

That's about 445 wasted job-minutes in ~9 hours, roughly 1,200/day at the current agent-PR push rate. Those runs also hold runners the live runs need. In the same window several npm/pnpm runs show failure but none of their jobs ran a step: they sat queued with no runner and were then cancelled, e.g. 37368805617 (build queued 18 min, zero steps) and 37365426182 (12 install-proof legs queued ~30 min, zero steps). I can't say from the API alone why GitHub cancelled them, but fewer stale jobs in the queue can only help.

Root cause

These three workflows have no concurrency: block. The others got one earlier, and these were missed.

Fix

Add a top-level group to each, the same pattern the others use:

concurrency:
  group: <wf>-compat-${{ github.event.pull_request.number || github.run_id }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

This differs from the other workflows in one place: non-PR events use github.run_id, not github.ref. Even with cancel-in-progress: false, GitHub keeps only one pending run per group. A third main push arriving while one main run is in progress and one is queued would cancel the queued one. With run_id, every main push and workflow_dispatch runs to completion, exactly as today. Only an older run on the same PR gets cancelled.

Proof

• actionlint 1.7.7 is clean on all three files, before and after. PyYAML parses them.
• No group name collides with an existing one (grep -rn 'group:' .github/workflows).
• None of the three workflows saves a shared cache from a PR run, so cancelling one can't leave a cache half-written.

Also in this PR: e7026a2 cherry-picks #878's fix (it routes the Gradle/JVM digests through utils::digest). On main, production_digests_go_through_the_helpers currently fails, so test/coverage/test-release are red on every PR. The pick becomes a no-op once #878 lands.

Where each test still runs

Nothing is removed. Every leg still runs on every PR head commit, every main push and every dispatch. The only runs dropped are PR runs for a commit that already has a newer push. Required-check names are unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EQTUzCY6pkBLc3BNJhz9Nu

Generated by Claude Code