ci(release): publish the GitHub release from CHANGELOG.md - #50

What and why

CI now creates the GitHub release of a tag and announces it, instead of a person doing it after the tag's run. Until now a tag could publish the image and chart and still end up with no release and no announcement.

• CHANGELOG.md holds the release notes, newest first. The section of a version (## vX.Y.Z: headline, then the notes) is written in the version change. It starts with v0.16.1, copied from its GitHub release with the group headings one level down (###); earlier releases keep their notes on GitHub.
• scripts/release/notes.sh prints the title or the notes of a version's section. It refuses a version with no section, with two, or with an empty one, and leaves a ## line inside a code block in the notes.
• ci.yml gains two tag-only jobs after release:
  • github-release creates the release from that section. It is the only job with contents: write; the release job keeps its read-only token. A re-run leaves an existing release alone.
  • announce calls the shared release announcement workflow (pinned to f7202aa) to post the release and its notes to Discord. A release made with the workflow's own token starts no release workflow, so it has to be called here.
• release-announce.yml stays for a release published by hand (after a failed release job) and for a manual re-announcement.
• make check fails for a chart version without notes (TestChartVersionHasReleaseNotes), so the notes cannot be forgotten before tagging.
• docs/development.md: the release procedure.

Hygiene allowlist

ci.yml now names the shared workflow too, so the allowlist entry from #49 covers .github/workflows/*.yml instead of one file. The form is unchanged: only that workflow, only pinned to a 40-character commit. The scan test shows a branch reference in a workflow still hits, and so does the same line in a document.

I tried two ways to keep a single reference (calling release-announce.yml from ci.yml). ./… is flagged by zizmor 1.32 (self-repository), and $/… is not accepted by the pinned actionlint 1.7.12, so ci.yml calls the shared workflow directly, as the other repositories do. Two pins have to move together; both files say so.

How it was tested

• go test ./internal/hygiene/: the new TestReleaseNotesAreTheVersionsSection (exact version, not a prefix of it; stops at the next version; code-block ## kept; missing, duplicate and empty sections refused) and TestChartVersionHasReleaseNotes, plus the lab-identifier scan.
• The github-release step run locally with gh stubbed: for v0.16.1 it calls gh release create v0.16.1 --verify-tag --title "v0.16.1: usage figures stay in their cards" --notes-file … with the section's text; with an existing release it does nothing; for a version without a section it fails with the script's message.
• actionlint (the pinned one, and 1.7.12 with shellcheck), zizmor --config .github/zizmor.yml .github, scripts/ci/links.sh offline, shellcheck on the script.
• Not tested: the two new jobs themselves. They run only for a tag, so the next release is their first run. The announce job's call is the one that already ran for v0.16.1 from release-announce.yml.

Checklist

• make check passes. (left to CI)
• Generated files are regenerated with make generate and committed. (none affected)
• Commits follow conventional commits and are signed.
• Tests cover the change; no assertion was weakened. (the allowlist entry's path is wider, see above)
• Docs are updated where behaviour, settings or the API changed.
• No lab identifiers: fixtures and docs use example.com, the documentation IP ranges and neutral names.
• A new plugin has a demo twin. (no plugin)