A label carries no push, so tagpr needs a way to be run by hand - #3
Merged
Merged
Conversation
tagpr reads the major/minor label WHEN IT RUNS, and its only trigger was a push to main. The release pull request is the next thing merged after the last feature merge, so labelling it `tagpr:minor` fired nothing and the merge would have tagged a patch. Measured: the label sat correctly applied and inert until the previous run was replayed. workflow_dispatch rather than `pull_request: labeled`, which would automate it and check out the pull request HEAD -- a tagpr run on a feature branch, which the trigger comment already rules out.
Merged
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.
Adds
workflow_dispatchtotagpr.yml, and records why a non-patch bump needs it.The bug
tagpr reads the
tagpr:minor/tagpr:majorlabel when it runs, and its only trigger waspushonmain. Labelling carries no push, so the ordering is a trap:main→ tagpr updates the release PR at the patch default.tagpr:minor.mainagain — the release PR is the next merge.Hit for real on the v0.3.0 release: the label sat correctly applied and completely inert until the previous run was replayed by hand. It self-heals only if another feature PR happens to be merged after labelling, which is the opposite of the natural order.
Why not
pull_request: labeledIt would automate this, and it is the wrong tool. That event checks out the pull request HEAD, so labelling any feature PR would point tagpr at a feature branch — the run the trigger comment in this file already rules out. Guarding it takes a
head_refcondition plus a pinned checkoutref;workflow_dispatchtakes one line and has no such edge.The release step is now: label →
gh workflow run tagpr.yml.CLAUDE.md's version-pin rule says so too, since that is where a release is looked up.Testing
test/all.shgreen. No behavior change outside CI configuration.