Skip to content

Build the release notes from the changelog - #50

Merged
tonytonycoder11 merged 1 commit into
mainfrom
ci/release-notes-from-changelog
Jul 31, 2026
Merged

Build the release notes from the changelog#50
tonytonycoder11 merged 1 commit into
mainfrom
ci/release-notes-from-changelog

Conversation

@tonytonycoder11

Copy link
Copy Markdown
Contributor

Kdrant's five releases were written by hand. Kmemo's workflow extracts them from CHANGELOG.md, which
is the better arrangement: a release note composed separately is a second copy of what the changelog
owns, and the two drift the first time one is edited without the other. This ports that step over, so
the two repositories release the same way.

  • The workflow extracts the section for the tag with awk and creates the release from it.
  • An empty section fails the release. A tag whose version the changelog does not mention is a
    mistake worth stopping for, not a release with a blank body.
  • Relative links are deliberately left alone: GitHub resolves them against the tag, so
    [STABILITY.md](STABILITY.md) in the v1.2.0 notes points at
    blob/v1.2.0/STABILITY.md — the released revision, not whatever main says later. Verified against
    Kmemo's rendered v1.1.0 page.
  • contents: readcontents: write, which creating a release requires.

Dry-run against the current CHANGELOG.md: 1.2.0 → 7 817 bytes, 1.1.0 → 1 048, 0.1.0 → 1 546,
and a version that does not exist → 0 bytes, which is the case that now fails the job.

The five existing releases have already been rewritten by hand from their changelog sections, so the
back catalogue and everything from 1.3.0 onward will read the same.

The five existing releases were written by hand, which is a second copy of what
CHANGELOG.md already owns and the two drift apart the first time one is edited
without the other. The workflow now extracts the section for the tag and creates
the release from it, and fails when that section is empty, because a tag whose
version the changelog does not mention is a mistake worth stopping for rather
than a release with a blank body.

Relative links are left alone on purpose: GitHub resolves them against the tag,
so a link to STABILITY.md from the v1.2.0 notes points at STABILITY.md as it was
in v1.2.0, not at whatever main says a year later.

Creating a release needs contents: write, so the workflow's read permission moves
up. It was only ever reading to build and publish.
@tonytonycoder11
tonytonycoder11 requested a review from a team as a code owner July 31, 2026 09:01
@tonytonycoder11
tonytonycoder11 merged commit 8064cec into main Jul 31, 2026
6 checks passed
@tonytonycoder11
tonytonycoder11 deleted the ci/release-notes-from-changelog branch July 31, 2026 09:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant