ci: run-level concurrency and bounded browser install - #179
Merged
Conversation
Job-level concurrency groups cancel superseded runs piecemeal: each matrix job of the old run fails its own group, the aggregate reports failure instead of cancelled, and because matrix jobs only enter their groups after verify finishes, start order can invert across runs and an older run's late matrix job can cancel a newer run's in-progress job. A single workflow-level group cancels a superseded pull request run atomically and queues pushes to main without cancelling release runs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The webkit job on #177 was killed by the 30-minute job timeout after apt-get update hung fetching archive.ubuntu.com inside playwright install --with-deps; the kill reports the job as cancelled and fails the aggregate. A step-level cap surfaces a mirror stall in 10 minutes instead of consuming the whole job budget. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Updates the CI workflow to use a single workflow-level concurrency group so superseded PR runs cancel as a unit (instead of job-by-job), while keeping push runs on main queued (not cancelled).
Changes:
- Add workflow-level
concurrencykeyed by${{ github.workflow }}-${{ github.ref }}, withcancel-in-progressenabled only forpull_requestevents. - Remove job-level
concurrencyblocks fromverifyand the compatibility matrix jobs.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Contributor
|
🎉 This PR is included in version 11.2.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
concurrencyblocks onverifyand the compatibility matrix with a single workflow-level group; superseded pull request runs now cancel atomically instead of job by job. Pushes tomainqueue (cancel-in-progressonly forpull_request), so release runs are never cancelled.Install browser runtimestep attimeout-minutes: 10.What actually happened on #177
Diagnosed from the run history, not the hypothesis in the issue:
gh run rerun --failed(run 32295425657 attempt 1) was not cancelled by a concurrency group. ItsInstall browser runtimestep (playwright install --with-deps webkit) hung onapt-get updatefetchingarchive.ubuntu.comat 19:54:40Z and sat silent until the job'stimeout-minutes: 30killed it — annotation: "The job has exceeded the maximum execution time of 30m0s". A timeout kill reports conclusioncancelled, which made it look like a concurrency cancel; the aggregate then correctly failed.compatibility-browser-webkit-CI-refs/pull/177/mergeexists"), leaving a redfailureaggregate on the old run instead of a cancelled run. And because matrix jobs only enter their groups afterverifyfinishes, start order can invert across runs: an older run whoseverifyfinishes later can cancel a newer run's in-progress matrix job. Run-level grouping removes both, and GitHub orders run-level cancellation by run creation.Race proof
Two rapid pushes to this branch, second push landing while the first run's full matrix was in progress:
f3034b0-> run 32324091171; all 5 matrix jobs in progress by 02:17:57Z.c28b5c2-> run 32324150731.cancelledatomically; every cancelled job carries the single run-level annotation "Canceling since a higher priority waiting request for CI-refs/pull/179/merge exists" -- no per-target group cancellations. (Itsif: always()aggregate still reports failure on the superseded SHA; only the latest SHA gates the PR.)Verify SDK, all 5 matrix targets, andCompatibility resultsucceeded with zero intra-run cancellation and no rerun.Verification
vp run verifyvp run test:live,vp run test:compat, single-target live commands):actionlint .github/workflows/ci.ymlcleanNotes
Fixes #178