Repository navigation
ci: a label CI does not read no longer starts a full CI run - #29747
Conversation
ci.yml and cmux-vm.yml trigger on labeled/unlabeled for the labels they read (full-ci, dev-build; cmux-vm-breaking-change-ok). Any other label event, such as a risk:* swap, now skips every job and runs in a concurrency group of its own, so it neither queues behind, replaces nor cancels the real run at that head. tests/test_ci_label_events_skip_full_ci.py fails a label-triggered workflow that neither guards its jobs nor says why it reacts to every label. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-93043e213c5bbc5a6a17
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
Shipped in:
|
|
Owned by an agent session · session |
|
Found 21 test failures on Blacksmith runners: Failures
...and 11 more test failures. View all on Blacksmith
|
Review at 336d0db: a skipped ci-status newer than a red or pending one reads as passing to gh-merge-green, which takes the newest check by name. ci-status now runs on every label event (into feat-cmux-next it passes at once), and the skip applies only to pull requests into feat-cmux-next, so main's required checks are never superseded by a skipped run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-93043e213c5bbc5a6a17
|
Review (codex gpt-6-astra high, router-review range 7f26639..5ca065b): SHIP at 5ca065b No correctness findings. Focused CI tests passed. Follow-ups: none The earlier BLOCK at 336d0db (a skipped |
The test execution registry needs a job that pull requests into feat-cmux-next run to execute it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-93043e213c5bbc5a6a17
…guard Its small evaluator has no '!'; the guard has its own test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-93043e213c5bbc5a6a17
Review at 9d793d0: a label event the workflow skips leaves a newer skipped run of each job, and newest_checks took it over a failed one, so the batch admitted a PR whose VM check was red. A skipped newest run now gives way to the newest run with a verdict, as a cancelled one already did (merge_guard's newest does the same). Red without the fix, green with it: tests/test_next_batch_groups.py::GroupCycle::test_newest_run_edge_cases. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-93043e213c5bbc5a6a17
![Fix with [code]smith](https://pr-comments-assets.blacksmith.sh/codesmith/fix-with-codesmith-light-3x.png)
Leo (2026-10-31): "JUST MERGE" "IT IS BINARY DONE OR NOT DONE".
Problem
ci.ymltriggers onpull_requestlabeled/unlabeled, so every label change,risk:*swaps included, started a second full CI run at the same head. On #29618 the duplicate run 41241282080 sat queued for over an hour behind the first one (label runs share its concurrency group and don't cancel), and while it was pending the webview gate kept waiting.cmux-vm.ymlhad the same trigger withcancel-in-progress: true, so any label change cancelled and restarted its check.What changed
ci.yml, for pull requests intofeat-cmux-next: every job butci-statusgets one guard that is false only for a label event whose label is notfull-ciordev-build(the two labels it reads).ci-statusstill runs on those events and passes at once into feat-cmux-next, because a skippedci-statusnewer than a red or pending one would read as passing to a newest-by-name gate likegh-merge-green(review finding at 336d0db). PRs into other bases (main) keep re-running as before, so main's required checks are never superseded by a skip. The concurrency group gets a-label-<run_id>suffix for those events, so the skipped run doesn't wait behind the real run, replace a pending one, or cancel anything. It finishes in seconds with every job skipped.full-cianddev-buildwork as before.scripts/ci/next_batch.py(risk:high, since it touches a merge enforcer):newest_checksnow treats a skipped newest run like a cancelled one and falls back to the newest run that has a verdict. Without this, a label run's skipped jobs (VMcheck,web) would hide an earlier red from the batch queue (review finding at 9d793d0). merge_guard'snewestalready works this way. Red without the fix, green with it:tests/test_next_batch_groups.py::GroupCycle::test_newest_run_edge_cases.cmux-vm.yml: same pattern (feat-cmux-next only), keyed oncmux-vm-breaking-change-ok.risk-tier,merge-freeze,pr-capture-check,pr-perf-section-check,backend-migrations,cmux-next-batch(debounce),cmux-next-mediaandcmux-next-motion-golden(already gated on their label).Test
tests/test_ci_delta_since_green.pydrops the guard before its small evaluator, which has no!, runs. The new test also runs as a step in ci-guards.yml'scigroup.New
tests/test_ci_label_events_skip_full_ci.py(linux-guard lane). Every label-triggered workflow must be either GUARDED (its labels listed; every job a label event could start ends with the guard; its concurrency group isolates other label events) or in REACTS with a reason. It also evaluates the guard:synchronize,opened,push, its own labels and arisk:highlabel into main give true;risk:high,risk:normalandready-to-landgive false. It fails on the base workflows (4+ job failures) and passes on the head. I updated one existing assertion (linux-preflight) that pinned the oldif:text.test_ci_pr_runs_cancel_superseded.py,test_ci_linux_compile_runners.pyandtest_ci_linux_single_size.pypass, and actionlint output is unchanged.Observed / Not run
test_ci_workflow_run_sources::test_ci_failfast...andtest_ci_change_areas::test_repository_helpers_route_by_where_they_runfail the same way on base (notestsjob; owned_pool_rescue route).Changelog
none
Agent session: agent session
🤖 Generated with Claude Code