One-click release tagging from the Actions tab#4
Merged
Conversation
New Tag Release workflow: run it from the Actions tab with a vX.Y.Z version and it validates the format, tags main, and starts the existing Release workflow. Tags pushed with the default GITHUB_TOKEN do not fire push-triggered workflows, so the release is dispatched explicitly and release.yml gains a workflow_dispatch trigger for that handoff. Also pins goreleaser-action to '~> v2' instead of latest — unpinned "latest" is how the lint job silently broke, and the release pipeline had the same exposure.
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.
Cutting a release currently means running git commands on a machine with the repo cloned. This adds a Tag Release workflow so it's one click from the Actions tab (works from a phone): enter a
vX.Y.Zversion, and it validates the format, refuses existing tags, tagsmain, and hands off to the existing Release pipeline — which still runs tests and the startup benchmark before GoReleaser publishes anything.One GitHub quirk handled explicitly: tags pushed with the default
GITHUB_TOKENdon't fire push-triggered workflows (recursion prevention), so the tagger dispatchesrelease.ymldirectly at the new tag, andrelease.ymlgains aworkflow_dispatchtrigger for that handoff.Also pins
goreleaser-actionto~> v2instead oflatest. Unpinned "latest" is exactly how the lint job silently broke (golangci-lint v2 rejecting the v1 config), and the release pipeline had the same exposure.README's release-process section documents the new flow. Deliberately not adopting semantic-release/release-please: automatic tagging on every merge would ship straight to fleet login shells, and generated changelogs would replace the hand-written CHANGELOG. The human decides when; the machinery does everything else.
Generated by Claude Code