ci(release): lead draft release notes with a Get started + Download header#801
Conversation
…eader The release-draft workflow produced a bare 'What's Changed' list, so every draft had to be hand-edited to add docs and docker-pull links before it was useful to a new user (the Kong-style entry points our published releases show). Make that automatic: a version-stamped header template (.github/release-notes-header.md) with docs + self-hosted quickstart links and the 'docker pull ghcr.io/api7/aisix:X.Y.Z' command is spliced above the auto-generated notes. release-draft.yml now checks out the repo, stamps the tag version into the template, and appends GitHub's generated notes. RELEASING.md updated: the header and full-changelog link are pre-filled, so polishing means inserting highlights in the middle, not re-adding the install snippet. Edit the template, not each release, to change the header.
|
Warning Review limit reached
Next review available in: 59 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…Changed The header PR fixed the top of the draft but left the middle a bare auto-generated commit list — the mechanical part maintainers had to restructure by hand every release. Seed the themed-section skeleton (headline, highlights, routing/guardrails/observability/security/API/MCP&A2A, breaking-changes) as an HTML comment right after the header divider, so every draft opens with the house structure inline instead of only in RELEASING.md. The comment is invisible in published output, so an unpolished draft still renders cleanly.
Address independent-audit findings on the release-draft header: - MEDIUM: a -rc draft printed a `X.Y` rolling tag (e.g. 0.5.0-rc) that docker/metadata-action never publishes for pre-release semver. Move the rolling-tags sentence into a __ROLLING_TAGS__ template slot and branch it: stable releases keep 'Rolling tags (X.Y, latest)…'; prereleases say 'Other image tags…' with no copy-pasteable tag that would 404. - MEDIUM: align actions/checkout to @v6, the repo-wide convention (every other workflow pins @v6); the new step had @v4. - LOW: fall back to a bare 'What's Changed' heading if generate-notes errors, so a transient API hiccup still yields a draft with the header.
Independent audit — resolved (no HIGH)Cold audit (verified against
Verified locally: YAML lints clean; assembled body for both Rebased onto @moonming's |
✅ Action performedFull review finished. |
1 participant
What & why
Follow-up to the v0.4.0 release: its notes were a bare auto-generated
What's Changedlist, so I hand-added a Get started + Download header (docs, self-hosted quickstart,docker pull) — the same Kong-style entry points our published releases show. This PR makes that header automatic for every future draft instead of a manual step.Changes
.github/release-notes-header.md(new) — the header template: Documentation + self-hosted quickstart links, and a version-stampeddocker pull ghcr.io/api7/aisix:__VERSION__block.__VERSION__/__MINOR__are substituted from the tag..github/workflows/release-draft.yml— now checks out the repo, stamps the tag version into the template, appends GitHub's generated notes (via thereleases/generate-notesAPI), and creates the draft with--notes-file. Behavior otherwise unchanged: still draft-only, still no-op if a release already exists, still flags--prereleasefor-rctags.RELEASING.md— step 2 updated: the header + full-changelog link are pre-filled, so polishing = inserting highlights in the middle; change the header via the template, not per release.Notes / accuracy
v(0.4.0), matchingdocker-image.yml's output; the git tag staysv0.4.0.__MINOR__is${VERSION%.*}— exact for stable (0.4.0→0.4); for-rctags it's approximate, which is why the header phrases rolling tags as "listed on the package page" rather than hard-claiming them.v0.4.0renders correctly (header →---→ What's Changed → Full Changelog).Test plan
vX.Y.Ztag push produces a draft whose body leads with the Get started + Download header above What's Changed.docker pullline in the draft resolves (image tag published bydocker-image.yml).🤖 Generated with Claude Code