You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ci: switch ci-status's hold-label and kill-switch checks to merge-holds.mjs labelHolds and switchHold #10835
The merge-queue hold labels (do-not-merge, the human-gated label, pr-verify-failed) and the lanes kill switch are stated twice once the #10747 pull request merges: as labelHolds and switchHold in .github/scripts/pr-merge/merge-holds.mjs, which select-tests runs through queueHolds before the lanes, and as bash in ci-status's Fail a queued pull request carrying a hold label and Fail a lanes App pull request its body or a member holds steps in .github/workflows/pr-require-checks.yml.
ci-status loads merge-holds.mjs from the merge group's base commit, so it cannot call those functions in the same pull request that adds them: that pull request's own merge group would fail closed and could never merge. The pr-unblock rule took the same two steps (#10737, then #10747).
Fix
Once the #10747 pull request is on main, switch both ci-status steps to the base module's labelHolds and switchHold (through the step's base-config checkout, failing closed when the module cannot judge), keep their error texts (the functions return ci-status's current texts; reconcile.test.mjs keys on the kill-switch one), and update scripts/ci-hold-merge-group.test.sh and scripts/ci-lanes-pr-hold.test.sh.
Done when
The label and kill-switch rules are stated once, in merge-holds.mjs.
Every state that fails ci-status today still fails it.
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: Medium
Uncertainty: Known
Flags: none
Blocked by: none
Understood: once the #10747 change is on main, replace the two bash hold checks in ci-status (hold labels and the lanes kill switch) with the base module's labelHolds and switchHold. The change keeps the current error texts, fails closed when the module can't judge, and updates the two hold test scripts. The aim is that the rules are stated once and every state that fails today still fails. The approach and done-when are clear. I found no likely duplicates among the open issues.
Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed - [ ] criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).
melodic-automation-lanes commented on Oct 29, 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: After the #10747 change is on main, ci-status's two hold steps call the base merge-holds.mjs labelHolds and switchHold, failing closed, with the same error texts and updated hold test scripts.
Should this wait until the #10747 pull request merges, since labelHolds and switchHold are not yet in merge-holds.mjs on main?
RECOMMENDED: Yes. Keep the issue held and re-refine once #10747 is merged, when the exported signatures and return shapes can be read and the criteria can name them. Basis: .base/.github/scripts/pr-merge/merge-holds.mjs has no labelHolds or switchHold (grep finds 0 matches); #10747 is open.
How should the human-gated label name reach labelHolds? ci-status now reads role_labels.human-gated from the base .work-item-tracker.json and defaults to needs-human.
RECOMMENDED: Keep the tracker read in the step, or have labelHolds read it from the base-config checkout; either way fail closed on an unreadable tracker. Basis: .github/workflows/pr-require-checks.yml:4783
Sources read
.github/workflows/pr-require-checks.yml:4761: the label-hold step is bash and checks do-not-merge, the human-gated label and pr-verify-failed, each with its error text
.github/workflows/pr-require-checks.yml:5200: the kill-switch check is bash and fails unless both variables read false
scripts/ci-hold-merge-group.test.sh:32: runs the label-hold step body
scripts/ci-lanes-pr-hold.test.sh:35: runs the lanes hold step body
To answer, post a comment that starts with this line:
**Decision recorded.** <answer>
Automated refinement by the lanes App. Answer with a comment whose first line is **Decision recorded.**.
Activity
github-actions commentedon Oct 29, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: Medium
Uncertainty: Known
Flags: none
Blocked by: none
Understood: once the #10747 change is on main, replace the two bash hold checks in ci-status (hold labels and the lanes kill switch) with the base module's
labelHoldsandswitchHold. The change keeps the current error texts, fails closed when the module can't judge, and updates the two hold test scripts. The aim is that the rules are stated once and every state that fails today still fails. The approach and done-when are clear. I found no likely duplicates among the open issues.Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Oct 29, 2026
Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed
- [ ]criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Oct 29, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: confirmed; its comment says why.melodic-automation-lanes commentedon Oct 29, 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: After the #10747 change is on main, ci-status's two hold steps call the base merge-holds.mjs labelHolds and switchHold, failing closed, with the same error texts and updated hold test scripts.
Related work
Open questions
RECOMMENDED: Yes. Keep the issue held and re-refine once #10747 is merged, when the exported signatures and return shapes can be read and the criteria can name them. Basis: .base/.github/scripts/pr-merge/merge-holds.mjs has no labelHolds or switchHold (grep finds 0 matches); #10747 is open.
RECOMMENDED: Keep the tracker read in the step, or have labelHolds read it from the base-config checkout; either way fail closed on an unreadable tracker. Basis: .github/workflows/pr-require-checks.yml:4783
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.**.