Repository navigation
ci: publish releases from the tag, and refuse a tag that skips the changelog - #90
Merged
Merged
Conversation
…angelog Cutting a release was four manual steps, and the one that mattered was the easiest to skip: stamping CHANGELOG.md. A tag pushed without it produces a release with no notes, a docs site that silently shows nothing new, and a tagged tree whose own changelog is missing its own entry. Nothing checked for it. Pushing a v* tag now verifies that the newest stamped section in CHANGELOG.md matches the tag, and fails with an explicit message naming both versions if it does not. It then publishes the GitHub release with that section as the notes, so the release page and the docs site are both fed from the same source rather than being retyped. The stamping stays a reviewed pull request. Deciding what shipped, and saying it clearly, is not a job for a script -- only the mechanical steps after it are automated. An optional final step dispatches a rebuild to the docs site. It is skipped cleanly when SITE_REBUILD_TOKEN is absent rather than failing the release, because the site already rebuilds daily on its own; the dispatch only shortens the delay. Guard logic verified against the real CHANGELOG before committing: v1.7.0 passes and extracts 104 lines of notes, v1.8.0 and v9.9.9 both fail by name.
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.
Answers "can this be controlled from CI/CD?" — mostly yes, and the part worth automating isn't the part you'd expect.
The trap it closes
Cutting a release was four manual steps, and the one that mattered was easiest to skip: stamping
CHANGELOG.md. A tag pushed without it gives you:CHANGELOG.md, not tagsNothing checked for any of it.
What the workflow does
On a
v*tag:CHANGELOG.mdmatches the tag. Fails with both versions named if not.SITE_REBUILD_TOKENrather than failing the release; the site already rebuilds daily, so this only shortens the delay.What stays manual, on purpose
Stamping remains a reviewed PR. I could have CI move
[Unreleased]entries under a version heading and push tomain— but deciding what shipped, and describing it well, is not a job for a script. It's also the step where today's changelog caught two real problems: a self-contradicting "Known gaps" entry, and eight### Fixedheadings that needed consolidating. A bot would have shipped both.There's an ordering trap too: stamping after tagging means the tag points at a tree whose changelog lacks its own entry. Keeping the stamp in the commit that gets tagged avoids that entirely.
Verified before committing
Ran the guard's exact shell against the real
CHANGELOG.md:Workflow YAML parses; steps resolve in order.
Your release flow after this
CHANGELOG.md→ PR → mergegit tag v1.8.0 && git push origin v1.8.0CI does the rest. And if you forget step 1, step 2 fails loudly instead of quietly publishing an empty release.