Repository navigation
Create the GitHub release from the changelog on a version tag - #69
Open
teknogeek0 wants to merge 1 commit into
Open
teknogeek0 wants to merge 1 commit into
teknogeek0 wants to merge 1 commit into
Conversation
Add ci/release-notes.sh. It reads the section for a tag from CHANGELOG.md, normalizes the headings and bullets, appends the compare link against the previous tag, and exits non-zero when no section matches. Add .github/workflows/release.yml. On a vX.Y.Z tag it builds the notes and creates the release. It skips a tag that already has a release, and takes a tag as input for a manual run. Check in CI that CHANGELOG.md has a section for the version in GIT-VERSION-GEN. Add a release-notes make target.
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
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.
The v0.20.0 tag published the container images but no GitHub release, because
nothing creates one. The v0.19.0 release was made by hand. This automates it.
ci/release-notes.sh
Reads the section for a tag from
CHANGELOG.md, normalizes###to##and*to-, and appends the compare link against the previous tag. Exitsnon-zero when no section matches, naming both header forms it looked for.
Tag to section: tries
vX.Y.Zfirst, thenvX.Y, because headers read### pgcopydb v0.20 (September 2026) ###while tags arev0.20.0.Run it locally with
make release-notes TAG=v0.20.0..github/workflows/release.yml
Triggers on a
vX.Y.Ztag, builds the notes and creates the release. Alsotakes a tag as a
workflow_dispatchinput, to backfill a release for anexisting tag.
Skips a tag that already has a release, so a re-run cannot overwrite notes
edited in the UI. Top-level
permissions: {},contents: writeon the jobonly,
persist-credentials: false, checkout pinned to the SHA the otherworkflows use.
It is separate from
docker-publish.ymlrather than a job inside it. Bothstart on a tag push, so the release can appear before the images. The trade is
distinguishable failures over strict ordering; the dispatch input covers
re-running either half.
Changelog gate
Three lines in the existing
docsjob check thatCHANGELOG.mdhas a sectionfor the version in
GIT-VERSION-GEN, so a version bump without a changelogentry fails at PR time rather than at tag time. It reuses the same extraction
the release workflow uses, so CI validates the text that becomes the notes.
DEF_VERonly moves in a release PR, so a feature PR is not required to touchthe changelog.
Checks
v0.20.0are byte-identical to the release published byhand, apart from a trailing blank line
v0.19.0,v0.17,v0.2produce correct output;v0.1correctly omits thecompare link, having no predecessor
DEF_VER=0.20and fails for a bump tov0.21v0.20.0zizmor: no findings forrelease.yml;run-tests-tiered.ymlreports thesame 16 findings with and without this change