Repository navigation
ci: Phase 1 — cancel-in-progress across all four repos #1780
Description
Phase 1 — cancel-in-progress across all four repos
Design: #1779 (doc §2.2, §4). Drew-approved outright 2026-10-28.
Cross-repo: one issue, one PR per repo.
Problem
Stale CI runs from superseded pushes queue to completion instead of
cancelling, holding GitHub runner-assignment slots ahead of live
work. 2026-10-28 sample (code#1599): queue branches carried 4–5
queued runs each; 127+ runs queued fleet-wide with ~4 in progress,
while per-job execution is only 0.4–14m — the wait is the disease.
Scope (audit gaps from the design inventory)
Apply the standard pattern — group keyed by ref for branch/PR runs,
cancel-in-progress: true, push-to-main runs keyed by run_id so
they are never cancelled:
concurrency:
group: ${{ github.workflow }}-${{ github.event_name == 'push' && github.ref == 'refs/heads/main' && github.run_id || github.ref }}
cancel-in-progress: true- developing-today/openchamber: add concurrency where missing —
nix-eval.yml,release.yml,vscode-extension.yml,
release-desktop-smoke.yml; set cancel onpr-review.yml
(currently cip=false). - developing-today/opencode:
publish*.yml— concurrency group
exists but cancel-in-progress is unset (defaults false); set it
for PR/branch runs. - developing-today/code:
goreleaser.yml(no block),
auto-assign.yml(cip=false; metadata-only, align for
uniformity). - dezren39/nix: audit confirms both PR workflows already carry
the pattern — verify and close this repo's slice with evidence.
Explicit non-goals
- code
jules.ymlis NOT touched: its job-level cip=false groups
are load-bearing (CI: Jules workflow_run subscribes to every workflow completion — 44 of the last 100 repo runs are skipped no-ops, and they share the concurrency group that can drop a real ci-failure-fix run #304 — a shared group let noise completions
cancel real Jules dispatch runs). - Scheduled singleton jobs (branch-cleanup, deploys) keep
cip=false; they are not checks.
Acceptance criteria
- One PR per repo (merge commit) applying the pattern to the
files above; no other workflow behaviour changes. - A superseded push on a test PR shows the earlier run
cancelled(evidence screenshot/comment on the PR). - A push-to-main run is never cancelled by a later push
(run_id keying) — verified on the first main run after merge.
Activity
developing-today commentedon Oct 28, 2026
CODE-722
dezren39 commentedon Oct 28, 2026
agent-note:v1
state: filed
Found via: filed this run — CI redesign pass executing Drew's 2026-10-28 directive (cancel-in-progress approved; PR tier = basic validation; full suite on main; Jules → issue → priority-90 Muse packet remediation chain). Design doc: files/designs/ci-fast-pr-full-main.md (repo-health goal workspace). Capacity evidence: #1599.
Agent: ci-redesign-filing
dezren39 commentedon Oct 29, 2026
dezren39/nix slice — Phase 1: VERIFIED, no change needed (no PR for Phase 1).
Audit of all 5 workflow files in dezren39/nix @ main c255385 (2026-10-29):
.github/workflows/mcpx-nixbuild.ymlgroup: ${{ github.workflow }}-${{ github.event_name == 'push' && github.run_id || github.ref }},cancel-in-progress: true(L47–48); push restricted tobranches: [main](L27).github/workflows/buffer-backup-lock-sync.ymlcancel-in-progress: true, header comment L36–38 documents the shape; pushbranches: [main](L27).github/workflows/branch-cleanup.ymlbranch-cleanup,cancel-in-progress: false; schedule + workflow_dispatch only.github/workflows/buffer-backup-renovate-bun-sync.ymlcancel-in-progress: false— documented in-file: a cancelled run between commit and push would strand the regenerated lock.github/workflows/opencode.ymlcancel-in-progress: false,queue: max; triggers areissue_comment/pull_request_review_commentonlyqueue: maxis paired with cip=false, so no cancel expression ever evaluates true for its issue events (openchamber#84 lesson checked)The two PR-triggering check workflows already carry the standard pattern, exactly as the design audit (§2.2) said. Phase 2/3 landed for nix in dezren39/darwin-nix#1078 (merged); see the comments on #1781/#1782. One tightening made there (not a Phase 1 gap): mcpx-nixbuild's group now keys every non-PR run by run_id, so the new nightly/dispatch runs can't be cancelled either.
dezren39 commentedon Oct 29, 2026
opencode slice — Phase 1 landed
PR: developing-today-forks/opencode#827 (merged 2026-10-29T05:42Z, merge commit). Merged on local-validation strength: the PR's own checks sat queued >20 min in the backlog this phase fixes (all pending at merge; none failed).
Changes:
publish.yml,publish-vscode.yml,publish-github-action.yml(+release-github-action.yml, same string form): concurrency was a bare string (cancel unset → false) → block form withcancel-in-progress: true; push-to-main, tag pushes and manual dispatches are keyed byrun_idso a release is never cancelled mid-publish; branch pushes stay ref-keyed and cancel on supersede. publish.yml keeps its version/bump group suffix.nix-eval.yml,storybook.yml: ref-keyed group → the §4 standard group (run_id on push-to-main).duplicate-issues,triage,review,opencode,pr-management,pr-standards) already carry per-issue/per-PR groups withqueue: max+ cip=false — bursts queue per item instead of replacing each other; left unchanged. Scheduled singleton/deploy workflows (branch-cleanup, deploys, models-snapshot, stats) keep cip=false deliberately, per the phase non-goals.queue: maxwith a cancel-in-progress expression that can evaluate true for issues/pull_request_target events. All 32 workflows YAML-parse clean.Not closing this issue — other repos' slices remain.
dezren39 commentedon Oct 29, 2026
Code slice landed: PR #2122 (merged, merge commit ea31e75).
Not closing: this issue is cross-repo (openchamber/opencode slices belong to their own workers).
dezren39 commentedon Oct 29, 2026
openchamber slice — Phase 1 done (with Phase 2 in the same PR).
PR: developing-today-forks/openchamber#752 — merged with a merge commit (checks sat queued >20 min in the backlog this phase fixes; merged on local validation strength: YAML parse + per-event concurrency audit, see the PR).
Concurrency changes, per file (trigger → group / cancel):
nix-eval.yml(pull_request on nix paths, workflow_dispatch) — was: no block. Now: §4 pattern, ref-keyed group,cancel-in-progress: true. Noqueue: max, no issues/pull_request_target trigger — the chore(deps): bump prettier-plugin-toml from 1.0.0 to 2.0.1 #84 trap cannot occur.release.yml(push tagsv*, workflow_dispatch) — was: no block. Now: group isrun_idfor tag pushes and dispatches (releases never cancelled), ref otherwise, cip=true. No queue:max.vscode-extension.yml(push tagsv*, workflow_dispatch) — same shape as release.yml.release-desktop-smoke.yml(workflow_dispatch only) — was: no block. Now: group keyed byinputs.repository+inputs.ref, cip=true — same-ref re-dispatch cancels the stale smoke, other refs unaffected.pr-review.yml(pull_request_target, issue_comment, pull_request_review_comment) — was cip=false +queue: max+ run_id-unique PR groups (nothing could ever cancel). Now:queue: maxremoved (pairing it with a cancel expression that evaluates true for pull_request_target is the openchamber#84 validation error); cancel expression is${{ github.event_name == 'pull_request_target' }}, and the group is per-PR for pull_request_target (superseded reviews now cancel) and per-comment-id for comment events (every review command gets its own group, so nothing is silently replaced — the openchamber#77 failure — and comment runs never cancel an active review).oc-review.yml(pr checks) — already had the right group/cancel (pr-checks-<PR number or run_id>, cip=true); unchanged in Phase 1 (its Phase 2 tier split is in the same PR, reported on ci: Phase 2 — PR-tier slimming (basic validation on PRs, full suite on main) #1781).Audit of the other 18 workflows (all 24 audited): the event bots already do the right thing and were left alone —
issue-intake.yml(per-issue group, run_id forissues, cip=false + queue:max),pr-intake.yml(per-PR group, cip=true, no queue:max),bot-help.yml/bot-summarize.yml(per-issue group, cip=false + queue:max — comment commands must queue, not cancel),oc-integration.yml/opencode.yml(per-PR/issue, cip=false + queue:max). Scheduled singletons/deploys (branch-cleanup,stale,opencode-update,nix-hashes,mobile-release,sdk-preview,jules-daily-upstream-sync) keep cip=false per the phase non-goals.label-merge-conflict,mobile-ci,docs-sourcealready cancel correctly on their paths.Before/after runs fired:
Not closing this issue — the other repos' slices are still open.
dezren39 commentedon Oct 29, 2026
Post-merge evidence for the openchamber slice (follow-up to the comment above):
pr checksrun on the merge SHA (05:49:48Z, head 2b79045) under its run_id-keyed group; it queued in the same backlog (not cancelled by the subsequent ⚡ Bolt: Optimize ProseMirror cursor rendering #753 merge push).11 remaining items
developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 7252 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
dezren39 commentedon Nov 4, 2026
agent-note:v1
event: picked_up
task: 7252 (triage, repo-health-code-pilot; repo-worker-code; OpenChamber scheduled lane aea12c82-c5af-4e5a-9b66-f8e360f87177)
state: claimed; fresh GitHub revalidation: #1780 OPEN with no hard-stop labels. The issue lists all four Phase-1 slices as merged: nix #1078, code #2122, opencode #827, openchamber #752. Current code main shows goreleaser.yml using run_id/ref keying with cancel-in-progress true. Commit 814c514 later applied the main-only-trigger and cancel-in-progress-everywhere directive, including branch-cleanup.
next: record whether any code fix remains and name the outstanding live-behavior evidence acceptance; no edits unless a real current gap is confirmed.
dezren39 commentedon Nov 4, 2026
Triage verdict — task 7252
Verdict: the code fix path is complete; no follow-up fix task is needed. Keep #1780 OPEN only for the remaining evidence-only acceptance.
Fresh GitHub state shows all four implementation slices linked to this issue are merged: dezren39/darwin-nix#1078, #2122, developing-today-forks/opencode#827, and developing-today-forks/openchamber#752. Current code main confirms .github/workflows/goreleaser.yml has the run_id/ref concurrency key and cancel-in-progress: true; the auto-assign.yml slice was later removed. The issue's older singleton exception list was superseded by the later 2026-10-30 commit 814c514, whose message records the main-only-trigger and cancel-in-progress-everywhere directive; that commit intentionally changed branch-cleanup from false to true. No workflow edits are made in this triage.
The remaining acceptance is empirical, not a missing code fix: the issue asks for a superseded-push run visibly cancelled and proof that a later main push cannot cancel the earlier main run. The prior code-slice triage (task 2393) noted that the first demonstration was not captured and recommended leaving this issue open until the owner accepts the run_id-keying structural evidence or the behavior is observed. This pass found no new implementation gap and creates no duplicate task.
Route: retain the issue for those two evidence items; otherwise the Phase-1 implementation slices are landed. This is a state-verification triage; no CI or code tests were run.
dezren39 commentedon Nov 4, 2026
agent-note:v1
event: done
task: 7252 (triage, repo-health-code-pilot; repo-worker-code; OpenChamber scheduled lane aea12c82-c5af-4e5a-9b66-f8e360f87177)
state: triaged; queue task completed. All four implementation PRs are merged and no code fix task is needed. Issue #1780 remains OPEN only for the two empirical acceptance items (superseded push cancellation and later main push not cancelling its predecessor); the current-state verdict is in the preceding comment.
labels: queue/claimed, status/in-progress, and work/assigned removed; non-flight labels retained.
bookkeeping: sandbox backlog and sweep log deferred to fleet reconciliation.