Repository navigation
Confirm ci-status's GITHUB_TOKEN can disarm auto-merge on a lanes push, and test the queue lookup by behaviour #9471
Description
Problem
#9450 adds a step to ci-status's lanes-hold step in .github/workflows/pr-require-checks.yml. On a synchronize event for an armed lanes App pull request, it calls disablePullRequestAutoMerge with the job's GITHUB_TOKEN. That token has contents: read and pull-requests: write.
Nobody has confirmed that this token can disable auto-merge:
- GitHub's docs say people with write permission, and the PR author, can disable it.
- peter-evans/enable-pull-request-automerge documents
pull-requests: writepluscontents: write.
A failed disarm only warns (::warning::). Two checks back it up:
- the merge queue's check for a pr-verify PASS at the exact head it merges;
- enable-auto-merge's scheduled reader, which disarms within 15 minutes.
If the token cannot disarm, the push-disarm is dead code on every push.
To do
- Confirm it live. Watch the first push to an armed lanes App pull request after fix(pr-merge): require a pr-verify pass before a lane pull request merges natively #9450 merges. One of two things shows up in ci-status's
Fail a lanes App pull request its body or a member holdsstep log:- the "native auto-merge is off" line, which means the token can disarm;
- the warning, which means it cannot.
- If it cannot (S1): choose between these, and do not widen ci-status's permissions without an owner decision:
- drop the step;
- move the disarm to a job that holds a token that can disarm.
- S3:
test_verify_rules_sync.pyTheQueueCheckAndTheGateAgree.test_the_lookup_names_and_origin_are_the_gate_schecks the workflow body's source text. Replace it with tests of how the bash body behaves:- run it against stubbed reads, as
scripts/ci-lanes-pr-hold.test.shdoes; - give it the gate suite's run records;
- compare its allow and refuse answers with the gate's.
- run it against stubbed reads, as
Refs: #9450
Activity
github-actions commentedon Oct 23, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
Understood: after #9450 merges, confirm that ci-status's GITHUB_TOKEN (contents: read, pull-requests: write) can disable auto-merge on a push to an armed lanes App PR. If it can't, either drop the step or move the disarm to a job with a token that can; don't widen ci-status permissions without an owner decision. Also replace the source-text test for the queue lookup with behavioural tests that run the bash body against stubbed reads.
Part 1 depends on #9450 merging and on a live push, which an unattended run can't do. Parts 2 and 3 can be checked in the repo. No likely duplicates found.
Automated triage, applied by the lanes App.
kyle-sexton commentedon Oct 26, 2026
Released for re-triage under the owner's 2026-10-26 rule: a person is involved only for "1. A change in original intent/vision 2. Something comes up during implementation ... that alters intent/vision or the primary design 3. If there is a HIGH/CRITICAL security issue". None applies here, so the hold label came off and intake triage runs again now.
To hold this issue again, add
needs-human(orstatus: needs-decision) and name which of the three applies.melodic-automation-lanes commentedon Oct 26, 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 26, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: confirmed; its comment says why.