ci: add commit messages to generated release notes - #368
Conversation
Append a "Commits" section (previous stable tag -> this release) to the cargo-dist announcement body before creating the GitHub release. Fetches full history/tags in the announce job, resolves the previous stable v<major>.<minor>.<patch> tag (ignoring canary-* tags), lists non-merge commits, and adds a Full Changelog compare link. Handles the first-release case with no previous tag. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ffd5ea53d3
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "Codex (@codex) review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "Codex (@codex) address that feedback".
| | grep -vFx "$RELEASE_TAG" | head -n1 || true)" | ||
|
|
||
| if [ -n "$previous_tag" ]; then | ||
| commit_range="${previous_tag}..${RELEASE_COMMIT}" |
There was a problem hiding this comment.
When this workflow is manually dispatched from a branch while inputs.tag identifies a different commit, the plan checks out that tag but RELEASE_COMMIT remains the dispatch ref's github.sha. This range therefore lists commits through the branch tip rather than commits contained in the release, while the notes and comparison link label them as belonging to RELEASE_TAG; resolve the endpoint from the tag or propagate the plan checkout SHA.
Useful? React with 👍 / 👎.
| previous_tag="$(git tag --list 'v[0-9]*.[0-9]*.[0-9]*' --sort=-version:refname \ | ||
| | grep -vFx "$RELEASE_TAG" | head -n1 || true)" |
There was a problem hiding this comment.
When manually publishing or recreating an older/backport release after a higher stable version exists, sorting every tag by version and merely excluding the current tag selects that newer release as previous_tag. The resulting newer..older log is empty or contains only divergent commits, and the changelog link compares unrelated releases; restrict candidates to tags merged into the release commit and select the nearest preceding one.
Useful? React with 👍 / 👎.
|
Latest downloadable build artifacts for this PR commit
Available artifact names
|
## Summary Follow-up to #368, which merged before its automated review comments were addressed. Both [Codex findings](#368) were valid P2 edge cases; this PR fixes them. ## Fixes **1. End the commit range at the released tag (not the dispatch SHA)** On a manual `workflow_dispatch` where `inputs.tag` points at a different commit than the run's `github.sha`, the range previously ran to the branch tip. Now the endpoint is resolved from the tag when it already exists, and falls back to the release commit otherwise (the normal push flow, where the tag is created at that commit in the same job). **2. Pick the previous tag from the release ancestry** Re-publishing an older or backport release while a higher stable version exists previously selected that newer tag as `previous_tag` (yielding an empty/divergent `newer..older` log and an unrelated compare link). The candidate search is now restricted to `git tag --merged <release commit>`, so it picks the nearest preceding stable tag in the release's own history. Also drops an unused `range_heading` variable. ## Validation Simulated both scenarios against the real repo history: - **Normal push** (`v0.19.3`): previous tag `v0.19.2`, lists v0.19.3's commits, compare `v0.19.2...v0.19.3`. ✅ - **Backport re-publish** (`v0.19.2` while `v0.19.3` exists): previous tag correctly resolves to **`v0.19.1`** (old logic wrongly picked `v0.19.3`), lists only v0.19.2's commits, compare `v0.19.1...v0.19.2`. ✅ Workflow YAML validated. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- sfk:created-approved-by --> Created by @AbhiPrasad <!-- sfk:slack-thread --> [Slack thread](https://braintrustdata.slack.com/archives/C0AQDETAVT3/p1789074523886719?thread_ts=1789074523.886719&cid=C0AQDETAVT3) Co-authored-by: Starfolk <noreply@starfolk.ai> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2 participants
Summary
Adds the commit messages between the previous stable release and the one being released into the auto-generated GitHub release notes.
Requested by Abhijeet Prasad (@AbhiPrasad) — include commit messages (current tag → last tag) in release notes.
What changed
In the
announcejob of.github/workflows/release.yml:fetch-depth: 0,fetch-tags: true).gh release create, a Commits section is appended to cargo-dist'sannouncement_github_body:git tag --list 'v[0-9]*.[0-9]*.[0-9]*' --sort=-version:refname(canary-* and other non-release tags are ignored).previous_tag..<release commit>as- <subject> (<short sha>).**Full Changelog**compare link.Example output
The section appended to the release notes for
v0.19.3(below cargo-dist's existing body):Validation
Ran the exact shell logic against the real repo for
v0.19.3; it resolvedv0.19.2as the previous tag and rendered a correct Commits section + compare link. Workflow YAML validated.🤖 Generated with Claude Code
Created by Abhijeet Prasad (@AbhiPrasad)
Slack thread