Repository navigation
fix(ci): fail ci-status when the kill switch stopped a review lane - #9836
Conversation
The review-lanes step in ci-status treated a lane the kill switch stopped as not required, so a head pushed while CLAUDE_LANES_DISABLED, CLAUDE_LANES_REPO_DISABLED or a lane's own switch was on passed ci-status with no review and could auto-merge. A stopped lane now fails with "'<check>' did not run on <head> (<run>): the kill switch is on. Re-trigger the PR once it is off." The kill switch pauses review; it never waives it. The admin bypass stays the break-glass. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…o's head The kill-switch verdict reflects the switch when the review run started, and "re-trigger the PR" invited an empty push. The error now says to re-run all jobs of the stopped run once the switch is off; a trusted re-run fires rerun-ci-status, which re-runs ci-status. The review-run lookup also took a fork's pull_request run on the same commit when it was the newest. It now keeps only runs whose head repository is this repository, as rerun-ci-status does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The head-repository filter on the review-run lookup would report a fork pull request's lanes as missing. When the pull request's head repository is not this repository, ci-status now prints the existing "a fork ... gets no review" line for each lane and fails before reading any run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Keep main's pass-notice and unproven verdicts (#9813) beside this branch's failing stopped verdict. The fork check reads main's new three-column lanes list. Main's two kill-switch notice tests now expect a stop to fail. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…itch-stopped-review
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
claude-review reviewed No findings. I reviewed all four changed files and the PR context. I did not run anything: the lane has no shell, and the test results in the PR description are author-claimed and unverified by me. What I checked
Closing issue: none. The PR context says "No related issue", so there are no acceptance criteria to check. Plugin manifests: the diff touches none, so no Trusted paths: no changed file matches the listed globs. Embedded directives: the PR body contains none. Cost: nothing here can start a real charge, so there is no hold. I left out one style point: the README edit joins the kill-switch sentence onto an already long line ( |
|
claude-security-review reviewed No security issues found in this pull request. The change tightens the
The protected-class list in The change has no cost or billing effect. critical-findings: 0 |
No related issue: owner rule that review lanes are the gate; raised by GitHub Support
Summary
ci-status treated a review lane the kill switch stopped as not required and passed. While
CLAUDE_LANES_DISABLED,CLAUDE_LANES_REPO_DISABLED, or a lane's ownCLAUDE_REVIEW_DISABLED/CLAUDE_SECURITY_REVIEW_DISABLEDwas on, any head pushed got a stopped review, passed ci-status, and native auto-merge could merge it unreviewed. Owner rule: review lanes are the gate; the kill switch pauses work and never waives review. The admin bypass stays the break-glass.Fix
Require both review lanes on this headin.github/workflows/pr-require-checks.yml: thestoppedverdict now emits::error::'<check>' did not run on <head> (<run url>): a kill switch was on when it started. Once it is off, re-run all jobs of <run url>; ci-status re-runs when it finishes.and setsfailed=1. The verdict reflects the switch when the review run started. A trusted person re-running that run firesrerun-ci-status(pr-feedback-dispatch.yml), so the fix needs no empty push.head_repository.full_nameis this repository, the same bindingrerun-ci-statusapplies. Before, a fork's run on the same commit could be the newest and decide the lane. This bug predates the PR. A PR whose head repository is not this repository fails up front with the existing "a fork ... gets no review" line, before any run is read, so the filter never turns a fork PR into "missing".docs/conventions/pr-pipeline/README.md("Both lanes review the head") and apr-pipelinechangelog fragment now say the same.Verification
bash scripts/ci-review-lanes.test.sh: with the new tests against the old workflow step, the three kill-switch cases, two fork-run cases (a newer fork run with the same SHA is ignored; a fork run alone leaves the lane missing) and a fork-PR case (fails as a fork, reads no run) each fail before their fix. With every fix in place: PASS=60 FAIL=0.actionlint .github/workflows/pr-require-checks.yml: exit 0.scripts/check-changelog-fragments.sh --checkand--check-required origin/main: both pass.check-affected --testsselects pass underpython3 -m unittest(babysit-prs 2877 OK, contract-clause-coverage 24 OK). pytest is missing on the authoring host, so the pull-request skill's verify gate could not record a pass.gh.Related
pr-require-checks.ymland the merge-lane scripts for other places that treat a kill-switch stop as a pass and found none. The lanes-App kill-switch step in ci-status already fails.clear-escalations,enable-auto-mergeandrefire-refusedstop on the switch instead of passing. The cost-hold reader in ci-status needs a recorded hold, so a stopped lane cannot clear it.docs/conventions/pr-pipeline/CHANGELOG.md4.x still describes the old behavior. That is released history and is left as is; the fragment records the change.🤖 Generated with Claude Code