Give gh a repo to talk to, so the auto-merge label step stops failing - #20
Merged
Conversation
The label-based sweep has never once run its write path. `automerge-eligible` exists in no repo in the fleet, and every scheduled sweep since the design landed reports `sweep acted on 0 PR(s)` -- because the sweep's first branch is `if label not in names`, and the label is never applied. appeler/pranaam#35, run 31283649110, has the whole story: ecosystem=uv group=security update-type=version-update:semver-minor eligible=true Run gh label create "$ELIGIBLE_LABEL" --force ... failed to run git: fatal: not a git repository ##[error]Process completed with exit code 1 Neither job checks out the repo; they do not need the code. Every other gh call passes a full PR URL and resolves the repo from the argument. `gh label create` takes no URL, so it falls back to reading a git remote, finds none, and exits 1. Under `bash -e` that kills the step, so `gh pr edit --add-label` never runs, and a failed step aborts the job, so the arming step never runs either. Reproduced outside CI in an empty directory -- same error string -- and confirmed that GH_REPO alone fixes it. Set at workflow level rather than on the one broken step: the sweep job was already setting it on two of its steps, so this removes that duplication and makes the next gh call added to either job correct by default. Fixed first in finite-sample/calibre#12; this is the same file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
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.
The auto-merge label step has been exiting 1 on every eligible Dependabot PR in every repo that carries this workflow.
automerge-eligibleexists in no repo in the fleet, and every scheduled sweep since the label design landed reportssweep acted on 0 PR(s)— the sweep keys off that label, so it classifies every PR asineligible (no policy label)and does nothing.The one classify run that ever reached an eligible PR — appeler/pranaam#35, run 31283649110:
Neither job checks out the repo — they do not need the code. Every other
ghcall passes a full PR URL and resolves the repo from that argument.gh label createtakes no URL, so it falls back to reading a git remote, finds none, exits 1. Underbash -ethe step dies there, sogh pr edit --add-labelnever runs; a failed step aborts the job, so neither does arming.Reproduced outside CI in an empty directory (identical error string) and confirmed
GH_REPOalone fixes it. Set at workflow level, which also removes the duplicate the sweep job carried on two of its steps.It fails closed, so nothing merged that should not have — but every run stayed green while the automation did nothing at all.
Fixed first in finite-sample/calibre#12; this is the same file.
Verification
actionlintexit 0 andzizmor --offlineexit 0, run separately.🤖 Generated with Claude Code