ci: publish a GitHub Release automatically on version tags - #7
Merged
Conversation
Pushing a tag created the module version but never the Release, so the repo front page kept advertising the previous version while proxy.golang.org already served the new one. v0.2.0 hit exactly that gap. Triggers on tags matching v*, takes the release notes from the matching CHANGELOG section, and fails loudly if that section is missing rather than publishing an empty release. Tags containing a hyphen are marked prerelease so a release candidate never steals the Latest badge. Uses the preinstalled gh CLI with the job token, no third-party action.
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.
Summary
Pushing a version tag created the module version but never a GitHub Release. The result was a repo front page still advertising the previous version while proxy.golang.org already served the new one — v0.2.0 sat in exactly that gap until the Release was published by hand.
This adds a workflow that closes it: push a
v*tag, get a Release.How it works
Triggers on
pushof tags matchingv*, extracts the notes from the matchingCHANGELOG.mdsection, and publishes withgh release create.Three deliberate choices:
It fails when the CHANGELOG has no matching section. Tagging
v0.3.0without a## [0.3.0]heading turns the job red with an actionable message rather than publishing an empty Release. A missing changelog entry should block the release, not be papered over.Tags containing a hyphen are marked
--prerelease. Av1.0.0-rc1will not steal the Latest badge from the current stable version. Everything else gets--latest.No third-party action. Uses the
ghCLI already present on the runner withgithub.tokenandpermissions: contents: write. Consistent with the zero-dependency posture of the library itself — one less third party with write access to releases.Verification
The awk extraction was run locally against the real
CHANGELOG.md:0.2.0— returns the full section, stops correctly at the next## [heading.0.1.0— the last section in the file; stops at the link-reference definitions in the footer instead of swallowing them.9.9.9— returns 0 bytes, so the job fails as intended.YAML validated.
Note on scope
The workflow is unproven end to end: v0.2.0 was released manually before it existed, so its first real execution will be the next tag. It also cannot fire retroactively — on a tag push GitHub reads the workflow from the commit the tag points at, so this has to be on
mainbefore the next tag is created, not after.