CI: cancel superseded dev/main push builds - newest SHA wins - #1729
Merged
Conversation
Push events in build.yml and sql-validation.yml now share a per-branch concurrency group with cancel-in-progress: true, so a dev merge landing while the previous merge's build is still running cancels the stale run. Baseline (2026-07-26, last 30 dev-push runs): 13 of 30 superseded mid-flight, ~60 runner-minutes spent finishing already-stale SHAs. Verified from the workflow graph before reversing the earlier never-cancel-push rule: push runs upload no artifacts (every upload-artifact in build.yml is release- or failure-gated; sql-validation.yml has none), and no download-artifact, gh run download, or workflow_run consumer exists anywhere in the repo. Release and merge_group runs keep unique per-run groups and stay uncancellable. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1 participant
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
Two CI-time items continuing #1712 (docs fast path) and #1715 (PR-level concurrency cancellation + caching):
build.ymlandsql-validation.ymlmove from unique per-run concurrency groups to a per-branch group withcancel-in-progress: true— a dev merge landing while the previous merge's build is still running cancels the stale run; newest SHA wins.releaseandmerge_groupruns keep their unique per-run groups and remain uncancellable.Baseline: last 30 push-event runs of build.yml on dev
Pulled via
gh api(runs + per-run jobs), 2026-07-26. A run is superseded when the next dev push'screated_atprecedes the run's completion; the reclaimable tail is the time it kept executing after that moment.Full per-run table (30 rows)
Verification: nothing consumes intermediate dev-push artifacts
The load-bearing claim behind reversing the earlier "never cancel dev/main push builds" rule. Proven from the workflow graph, not trusted:
What push runs upload: nothing. Every
upload-artifactstep in the graph, with its gate:Lite-unsignedif: github.event_name == 'release'Darling-unsignedLite-Velopack-unsignedDarlingViewer-Velopack-unsigneddarling-pg-failureif: failure()(diagnostics)darling-pg-failureif: failure()(diagnostics; nightly is untouched by this PR)sql-validation.ymlcontains noupload-artifactstep at all.Who downloads artifacts across runs: nobody. Repo-wide search for
download-artifact,gh run download,dawidd6/action-download-artifact,nightly.link, andworkflow_runtriggers: zero matches. The only artifact consumers anywhere are the four SignPathgithub-artifact-idinputs, and those read same-run step outputs (steps.upload-*.outputs.artifact-id), release-event-only.Releases build fresh on the
releaseevent — every publish/package/sign step runs inside the release run itself;vpk download githubpulls from GitHub Releases (the Velopack channel feed), never from Actions artifacts.Nightly builds its own tree from its own checkout (
ref: dev) and publishes to thenightlyGitHub release, not to workflow artifacts.Field deploys (DARLING01) publish locally from a checkout — consistent with the zero-consumer search; no deploy tooling in the repo pulls CI artifacts.
Conclusion: there are no "intermediate dev-push artifacts" to protect — push runs never create any. The justification for the reversal held under verification.
Edges considered and accepted:
darling-pg-failureupload. A persistent failure reproduces on the newest SHA with its own diagnostics; one that vanishes on the newest SHA no longer matters.buildandDarling PostgreSQL testsgate PRs, and PR-supersede cancellation has existed since CI intelligence: restore the classification the dorny v4 bump broke, cancel superseded PR runs, un-trap the nightly, bound the jobs #1715 — the superseding run always reports on the newest head. Push runs are not required-check contexts. Nothing stops reporting.What stays uncancellable (unchanged guarantees)
releaseruns: uniquebuild-run-{run_id}group,cancel-in-progressevaluates false. SignPath's manual approval gate can legitimately take hours; nothing can replace or cancel it.merge_groupruns: same unique-group treatment (CI: handle merge_group so enabling a dev merge queue is a safe one-click #1716's inert-but-ready wiring).push.branches: [main, dev], no tag filter).Validation
event && format(...) || fallback) is byte-for-byte the short-circuit pattern CI intelligence: restore the classification the dorny v4 bump broke, cancel superseded PR runs, un-trap the nightly, bound the jobs #1715 shipped, extended by one arm; both files parse (checked locally) and this PR's own CI is a full-matrix run (build.yml sits on therootanddarlingfilters), which executes the edited stanza.build.yml's push trigger isbranches: [main, dev]only — two rapid commits to a throwaway branch trigger no runs at all, and widening triggers just to test would be a real behavior change. The new behavior will demonstrate itself on the next rapid dev merge pair; I will link the cancelled run in a comment on this PR when one occurs.Merge queue (Task 2): cannot be enabled on this repo — reported, not shipped
The requested deliverable ("exact GitHub settings to enable merge queue on dev") contradicts a finding verified twice, most recently today:
422 Invalid rule 'merge_queue'(CI: handle merge_group so enabling a dev merge queue is a safe one-click #1716, 2026-07-26).erikdarlingdata/PerformanceMonitoris a personal-account repository, so no plan tier reaches it.What a queue would eliminate, measured against the baseline above: today's train merged ~20 PRs through the auto-merge + CHANGELOG-conflict-repush workflow. Each conflict re-push re-ran PR CI (~15-20 extra full builds over the evening; ~3m40s per single-area re-push after #1715), and the merges themselves produced the 13 superseded dev-push builds / 60m23s in the table. A merge queue serializes candidates so each PR validates exactly once against its final base: both costs go to approximately zero. This PR reclaims the superseded-push slice; the conflict-re-push slice remains structural until the repo is organization-owned.
If the repo ever moves to an organization, the settings are ready to click:
dev→ require merge queue; merge method Merge commit (matches repo convention).build+Darling PostgreSQL tests— both already handle themerge_groupevent (CI: handle merge_group so enabling a dev merge queue is a safe one-click #1716) and report a result on every queue run (the no-op/fast-path shapes still report).No
MERGE-QUEUE.mdis added: checked-in docs titled "how to enable" for a feature this repo cannot enable would mislead; #1716's CHANGELOG entry records the finding in-repo, and this section is the durable analysis.Constraints respected
actions/upload-artifactuntouched (held at v6 per CI: GitHub Actions pins are 1-2 majors behind (upload-artifact bump touches the SignPath release path) #1653; the dependabot ignore rule stands).🤖 Generated with Claude Code