Assemble release notes from changelog.d fragments - #34
Merged
Conversation
Picks up changelog.mk plus the two upstream fixes: TAG_NOTES_CMD in go-release.mk, and install-gitleaks in security.mk. Vendored copies are byte-identical to GNUMakefile-Snippets main.
Cutting v1.19.1 needed the CHANGELOG section extracted to a temp file by hand, because publish posts a notes file whole and the changelog held two releases by then. Fragments remove that step: make tag embeds the assembled notes in the tag body and publish reads them back. CHANGELOG.md is removed rather than kept alongside changelog.d, so there is one mechanism instead of two. Every line of it is preserved verbatim in the v1.19.0 and v1.19.1 GitHub releases, which was checked before deleting.
Replaces the download step inlined in the workflow with make install-gitleaks, which is pinned and checksum-verified upstream, so other repos vendoring the snippet do not each reinvent it. Adds make changelog-check to the quality gates: a stub or malformed fragment now fails the PR rather than silently dropping out of the notes at release time.
The gitleaks install step was added without accounting for the env block
already on the audit step, producing two env keys and a workflow that
failed to parse - zero jobs ran.
PATH is extended through GITHUB_PATH now. The previous
PATH: ${{ env.PATH }} was self-referential and would not have worked
even had the file parsed.
Verified with actionlint, which catches both; plain YAML parsing does
not, since duplicate keys are valid YAML.
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.
Adopts the two fixes just made upstream in the shared make snippets. No
.go,go.modorgo.sumchanges — build, release, and CI only.Release notes no longer need hand-editing
Cutting v1.19.1 required extracting a CHANGELOG section to a temp file by
hand:
publishposts a notes file whole, and by then the changelog held tworeleases, so publishing it would have repeated v1.19.0's notes inside the
v1.19.1 release. One file cannot be both a durable history and the payload for
a single release.
Each PR now drops a fragment in
changelog.d/. At release timemake tagembeds the assembled notes in the annotated tag body and
make publishreadsthem back with
--notes-from-tag. This is the mechanism already used incloudfoundry/stratos, so there is one convention rather than two.
CHANGELOG.mdis removed rather than kept alongsidechangelog.d/— keepingboth is the two-mechanism problem this is meant to solve. Every line of it is
preserved verbatim in the
v1.19.0
and v1.19.1
release bodies; that was verified line by line before deleting.
make changelog-checkjoins the quality gates, so a stub or malformedfragment fails the PR rather than silently dropping out of the notes at
release time.
CI installs gitleaks from the snippet
The v1.19.0 CI run failed because
make auditneeds gitleaks, which is asystem package the snippet could not install — so the workflow carried an
inlined download step. That step now lives upstream as
make install-gitleaks(pinned release, verified against the project's published checksums), so every
repo vendoring the snippet gets it instead of reinventing it.
The audit job keeps
fetch-depth: 0:gitleaks detectreads git history, andat depth 1 it scans one commit and reports clean whatever the history holds.
Verification
Locally:
make build test-race check auditall pass,changelog-checkpasses,and a
DRYRUN=yestag shows the assembled fragment text going into the tagbody. Vendored
mk/files are byte-identical to GNUMakefile-Snippetsmain.This PR is also the first exercise of
install-gitleakson Linux — it wasonly verified on macOS upstream, and the audit job is what proves it.