feat: release by workflow dispatch - #2
Merged
Conversation
Releasing meant tagging by hand and remembering to force-move the major tag afterwards. This does both from the Actions tab, given a patch, minor or major choice, and publishes the release with generated notes. The version comes from the existing tags. When no point release has been tagged yet -- which is the case now, since only the movable `v1` has ever existed -- it seeds from that major tag rather than starting at zero. Otherwise picking `minor` today would produce v0.1.0 and a `v0` tag, quietly leaving every `@v1` caller pinned to a tag that had stopped moving. Follows the release-pr action for pushing: checkout keeps no credentials, and `gh auth setup-git` grants them only for the tag push. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pushing tags meant configuring a committer identity, because `git tag -a` records a tagger and fails without one whatever permissions the token holds. That is unrelated to authorization, and hardcoding the bot's address to satisfy it was noise. Creating the refs through the API removes it: `contents: write` on the job is now the whole authorization story, the tagger comes from the token, and the job needs no git credentials at all -- so `gh auth setup-git` goes too. The only git left is reading tags to work out the next version, which needs nothing. The point tag stays annotated, created as a tag object and then a ref. The movable major tag becomes a lightweight ref pointing straight at the commit, which suits a pointer that moves better than carrying a tagger and a date from whichever release last moved it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The seeding case duplicated the major/minor/patch assignment just to reach the same arithmetic. Normalising the fallback to a version string instead lets both paths share the parse and the bump, and the step reads top to bottom: find the current version, bump it, check it is free. Behaviour is unchanged, including the ordering case sort -V exists for (v1.10.0 sorts above v1.9.0, which a lexical sort gets backwards). 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
2 participants
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.
Releasing meant tagging by hand and remembering to force-move the major tag afterwards. This does both from the Actions tab, given a patch, minor or major choice, and publishes the release with generated notes.
The version comes from the existing tags. When no point release has been tagged yet -- which is the case now, since only the movable
v1has ever existed -- it seeds from that major tag rather than starting at zero. Otherwise pickingminortoday would produce v0.1.0 and av0tag, quietly leaving every@v1caller pinned to a tag that had stopped moving.Follows the release-pr action for pushing: checkout keeps no credentials, and
gh auth setup-gitgrants them only for the tag push.