🏗️🔧：ask REST to take the label back off - #1819
Merged
Merged
Conversation
`gh pr edit` and `gh pr comment` reach for GraphQL, which wants organization permissions that removing a label and leaving a comment do not need. The app satisfies them today, so this works; tightening its permissions or installing it somewhere with fewer would break both silently, since one hides behind a `|| true` and the other only runs when something has already gone wrong. The REST endpoints need only the pull request permission the app already has, and the label one names a single label in the path rather than trusting a flag to be subtractive. Checked both ways: removing one label from a pull request carrying two leaves the other alone, and removing a label that is not there exits non-zero, which is what the `|| true` is for. Signed-off-by: Derek Lewis <DerekNonGeneric@inf.is> Assisted-by: Claude-Code:claude-opus-5
✅ Deploy Preview for gh-pages-openinf ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
DerekNonGeneric
added
the
commit-queue
openinf-commit-queue
Bot
removed
the
commit-queue
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prompted by your question about whether the queue would strip a pull request's other labels. It would not — but answering it turned up something worth fixing.
The answer, from a real run
Adding three labels to a merged pull request accidentally triggered a genuine queue run, which refused and took its label off:
--remove-labelis subtractive, not a replace. Renovate's pull requests, which arrive carrying three labels each, are safe.That run also showed the
if: github.event.label.name == 'commit-queue'guard doing its job: three labels emitted threelabeledevents, and the queue skipped the two that were not its own.What it turned up
gh pr editandgh pr commentreach for GraphQL, which wants organization permissions that removing a label and posting a comment do not need. The app satisfies them today, so this works. But tightening its permissions, or installing it on a repo where it has fewer, would break both silently — one hides behind|| true, and the other only ever runs when something has already gone wrong.The REST endpoints need only the pull request permission the app already has. The label one also names a single label in the path, rather than trusting a flag to behave subtractively.
Verified from my own terminal, whose token deliberately lacks
read:org:gh pr edit --remove-labelthe 'login' field requires ['read:org']gh api -X DELETE …/labels/buildon a PR labelledbuild, security[security]Verification
nps test— 16/16 tasks, 63/63 testslabeled, so nothing here can looplabels=[]and the comment my testing provoked was deleted