Repository navigation
pr-pipeline: stop ci-status starting red before both review lanes finish #12447
Description
Refs: #12284
Owner: Automation Lanes.
Owner gate. The security review lane is a control. If a design would let a PR merge before both review lanes complete on its head, it comes to the owner before building.
Summary
ci-status requires both review lanes on the head (.github/workflows/pr-require-checks.yml:6755 at cb8429f). Reviews usually finish after ci-status first reads them, so ci-status starts red. pr-feedback-dispatch.yml:575 (rerun-ci-status) then re-runs it.
Measured over 7 days: 790 re-run attempts, 14% of 5,515 PR runs of pr-require-checks. On 2026-11-01: 192 re-runs. Source: audit comment, gate #9.
Both lanes stay. The code-review lane also raises the cost hold (pr-review-hosted.yml:242-250), which is a billing control.
Options:
- Gate pr-verify or pr-merge's verdict on the reviews, rather than ci-status's first pass.
- Start ci-status's review read only once both lanes have finished.
Each option must still keep a PR from merging until both lanes complete on its head.
Done when
- A design that keeps "both lanes reviewed this head" as a merge precondition is posted here. If it would not, the owner decided it first.
- ci-status re-run attempts per day are measured before and after.
-
docs/conventions/pr-pipeline/README.md"Review-lane holds" describes the new order.
Activity
github-actions commentedon Nov 2, 2026
Proposed work class: work-class: structural
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
You want ci-status to stop starting red and being re-run, while "both review lanes reviewed this head" stays a merge precondition. A recorded decision exists:
#12447 (comment)
This settles the open design question. Nothing further is asked of the owner.
Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Nov 2, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: confirmed; its comment says why.melodic-automation-lanes commentedon Nov 2, 2026
Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.
Intended outcome: Remove the red-start and re-run churn of ci-status by deferring its review read until both review lanes finish on the head, while keeping "both lanes reviewed this head" as a merge precondition.
Related work
Open questions
RECOMMENDED: Start ci-status's review read only after both lanes finish, keeping ci-status as the single merge gate. Basis: judgment
RECOMMENDED: Approve only if ci-status stays a required check that is not green until both lanes have finished on the current head SHA. Basis: judgment
RECOMMENDED: Count rerun-ci-status re-run attempts per day from the pr-feedback-dispatch records over 7 days before and after, with a target near zero. Baseline: 790 per 7 days and 192 on 2026-11-01. Basis: judgment
RECOMMENDED: Split it out as a post-deploy check a person runs, since the after-measurement needs days of production data. Basis: judgment
Sources read
To answer, post a comment that starts with this line:
Automated refinement by the lanes App. Answer with a comment whose first line is
**Decision recorded.**.kyle-sexton commentedon Nov 3, 2026
Decision recorded.
Build option 2: ci-status starts its review read only once both review lanes have finished on the head, and stays pending (not green, not red) until then, so "both lanes reviewed this head" remains a merge precondition held by the one required check. Option 1 is not built: it moves part of the merge gate out of ci-status. The
costhold the code-review lane raises is unchanged. Basis: this issue's body (its gate applies only to a design that lets a PR merge before both lanes complete); AGENTS.md, "None of their checks is required;ci-statusis the only one". Written by the issue-triage session.docs/conventions/pr-pipeline/README.md"Review-lane holds" describes the new order.kyle-sexton commentedon Nov 3, 2026
Agent choice, not an owner answer. The decision record above was written by the issue-triage session under the owner's standing direction §1 (decide from evidence). The owner did not answer this question; the comment appears under the owner's login only because the session posts with that account.
github-actions commentedon Nov 3, 2026
The triage sweep dispatched intake triage for this issue (attempt 1 of 2).
melodic-automation-lanes commentedon Nov 3, 2026
Not admitted to the issue lane: it carries host-run. Admission takes the issue once each of those is met, when intake triages it again (
.github/actions/resolve-config/admission-rules.json).kyle-sexton commentedon Nov 3, 2026
Measured: #12797's
rerun-ci-statusworks, but lands 2 to 6 minutes after the last review, and its red message invites a manual re-run.On two heads on 2026-11-03 the job ran for both lanes and took the right branch each time. The run for the lane that finished last got a hosted runner 2 to 6 minutes after its review completed:
Both times a session re-ran ci-status by hand about a minute after the reviews finished, because the red message says "ci-status re-runs when the review finishes". The automatic run then correctly exited with "it read them", so each manual re-run cost an attempt and saved nothing. 323 pr-feedback-dispatch runs were created between 16:25 and 17:15Z; runner contention as the cause of the wait is unverified.
What this adds to this issue's scope:
pr-require-checks.ymlshould say the re-run comes from pr-feedback-dispatch within a few minutes and that no manual re-run is needed.rerun-ci-statusstart over a day (median and p90) as the baseline the redesign is judged against.Posted by the overnight session. This was generated by AI.