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
feat(pr-merge): remove the lane's own hold-path needs-human label after a trusted approval lifts the hold #10785
When pr-merge escalates a lanes App pull request for a hold path, it adds needs-human. ci-status already names the release: "an approving review of this head by a person on the trusted-actor list lifts it". Even so, the label stays until someone removes it, and the owner removed it by hand after approving on #10665, #10738 and #10745.
Acceptance criteria
On a reader run, enable-auto-merge deletes needs-human itself only when all of these hold:
The lane's newest refusal at the head names only hold paths, no cost hold stands, and the file listing was read whole.
A trusted person's approval lifts the hold path, bound to the head or carried under the merge-holds carry rules.
The newest labeled event for the label is the lanes App's, and it pairs with enable-auto-merge's refusal comment.
Since the label was last removed, no review-lane hold comment and no check-signed-commits hold comment stands.
Since the label went on, the lanes App wrote no pr-unblock escalation and no other marked comment, and no person commented, replied in a review thread or submitted a review other than an approval.
The head read again right before the delete is the head that was judged.
Otherwise the label stays. A failed read keeps it. A report-only run deletes nothing.
Safety constraints
It never removes a label a person applied, or a label another escalation (a pr-unblock escalation, a review-lane hold, a signed-commits hold) stands behind.
The control stays a trusted person's approval, the one ci-status applies.
The delete re-runs ci-status at the head (pr-require-checks.yml runs on unlabeled), so no hold is skipped.
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: High
Uncertainty: Known
Flags: none
Blocked by: none
Understood: when a trusted person's approval lifts a hold path on a lanes App pull request, enable-auto-merge should remove the needs-human label it added, but only under strict provenance, no-other-escalation and head re-read checks. Otherwise the label stays, and a report-only run deletes nothing. The body's criteria and the refinement comment's testable criteria are specific enough to start from. #9437 is related (same label's ownership rules), but it is not a duplicate.
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 28, 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: On a reader run, enable-auto-merge deletes the lane's own needs-human label from a lanes App pull request once a trusted person's approval lifts the hold path, under the stated provenance, no-other-escalation and head re-read checks, and otherwise keeps it.
Acceptance criteria
With REPORT_ONLY not false, enable-auto-merge issues no label delete and logs it would (a test asserts no DELETE call).
A test passes where the newest refusal names only hold paths, no cost hold stands, the file listing was read whole, and a trusted person's approval is bound to the head: the needs-human label is deleted.
A test passes where the approval is carried under the merge-holds carry rules (an earlier head whose every change since is a base merge): the label is deleted.
A test passes where the newest labeled event for the label is by a person, or is the App's but unpaired with enable-auto-merge's refusal comment: the label stays.
A test passes where a refusal names a cost hold or a non-hold-path reason, or the file listing was cut short: the label stays.
A test passes where a review-lane hold comment or a check-signed-commits hold comment was written or edited since the label was last removed: the label stays.
A test passes where, since the label went on, the App wrote a pr-unblock escalation or any other marked comment: the label stays.
A test passes where, since the label went on, a person commented, replied in a review thread, or submitted a non-approving review: the label stays; an approval alone does not keep it.
A test passes where any read fails, or the head read again before the delete differs from the judged head: the label stays.
A test passes where a delete is made at the judged head, and docs/conventions/pr-pipeline/README.md and its CHANGELOG.md describe the new removal, citing that pr-require-checks.yml re-runs ci-status on unlabeled.
The new logic reuses the existing provenance and marker rules of .github/scripts/pr-merge/clear-escalations.mjs and merge-holds.mjs rather than a second copy, and the existing pr-merge script tests still pass.
.github/scripts/pr-merge/enable-auto-merge.mjs:1115: REPORT_ONLY === "false" is the only write mode; humanGated label comes from the tracker config at line 1119
.github/scripts/pr-merge/enable-auto-merge.mjs:1212: refusalWrites adds the human-gated label and the refusal comment on a hold
.github/scripts/pr-merge/clear-escalations.mjs:6: removes only an App-set label under paired-comment, no-review-hold, no-person-activity rules; the pattern to reuse
.github/scripts/pr-merge/clear-escalations.mjs:73: a pr-merge escalation clears as head-moved only; it does not clear on a trusted approval, which is the gap
.github/scripts/pr-merge/merge-holds.mjs:1186: ci-status's hold-path reason says an approving review of this head by a trusted-actor person lifts it
.github/scripts/pr-merge/merge-holds.mjs:1374: ci-status logs the lifters and how the approval lifts a hold path
Automated refinement by the lanes App. Intake triages the issue again with it.
Activity
github-actions commentedon Oct 28, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: High
Uncertainty: Known
Flags: none
Blocked by: none
Understood: when a trusted person's approval lifts a hold path on a lanes App pull request, enable-auto-merge should remove the needs-human label it added, but only under strict provenance, no-other-escalation and head re-read checks. Otherwise the label stays, and a report-only run deletes nothing. The body's criteria and the refinement comment's testable criteria are specific enough to start from. #9437 is related (same label's ownership rules), but it is not a duplicate.
Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Oct 28, 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 28, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.melodic-automation-lanes commentedon Oct 28, 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: On a reader run, enable-auto-merge deletes the lane's own needs-human label from a lanes App pull request once a trusted person's approval lifts the hold path, under the stated provenance, no-other-escalation and head re-read checks, and otherwise keeps it.
Acceptance criteria
false, enable-auto-merge issues no label delete and logs it would (a test asserts no DELETE call).labeledevent for the label is by a person, or is the App's but unpaired with enable-auto-merge's refusal comment: the label stays.unlabeled.Related work
Sources read
Automated refinement by the lanes App. Intake triages the issue again with it.