fix: render only the latest release's notes, not the full history - #15
Merged
Conversation
Regression introduced in #13 (the consolidate-git-cliff-calls change). The old workflow used `--latest --strip all` on the render step, where `--latest` filtered the output to just the bumped release. When I consolidated to `--bump --context` + `--from-context`, I kept `--strip all` (whitespace handling) but dropped `--latest`, with the result that the context JSON contained EVERY release since repo inception and the render concatenated all of them into each new release's notes body. Symptom: v1.4.1 and v1.4.2 release pages have notes that include v1.4.0, v1.3.2, v1.3.1, … all the way back to v1.0.0. v1.4.0 (created before #13 landed) is clean. Fix is a one-word addition: pass `--latest` alongside `--bump --context` so the JSON only contains the bumped release. Render then has nothing else to render. No need for --latest on the --from-context call (which turns out to be ignored anyway — filtering has to happen at context generation time). Local verification: `git-cliff --latest --bump --context | jq 'length'` returns 1 (one release in the JSON); rendering that JSON produces a body with just the latest release's bullets + footer. Cleanup of the already-broken v1.4.1 and v1.4.2 release bodies is a separate, optional follow-up (gh release edit --notes-file).
5 tasks
fiunchinho
added a commit
that referenced
this pull request
Jun 3, 2026
…y bumps (#16) PR #15's "fix" for the full-history regression was wrong. I added `--latest` thinking it would filter the cliff context to just the bumped release; what it actually does in combination with `--bump` is return the latest EXISTING tag and silently drop the bump. Result: PR #15's merge ran the workflow successfully but computed `next: v1.4.2` (the existing tag), said "no releasable commits", and skipped tagging. We never got the v1.4.3 release that should have validated #15 itself. The right flag is `--unreleased --bump --context`: --unreleased : filter to commits not yet in any tag --bump : compute the bumped version from those commits --context : output as JSON Together they produce a single-release JSON for just the bumped version. Verified locally on a fresh clone at the PR #15 merge commit: returns `v1.4.3` (correct), one element in the JSON, renders cleanly with just the new release's bullets + Full Changelog footer. Acknowledging: this is the second swing at the same regression (originally introduced in #13, mis-fixed in #15). Lesson: end-to-end local testing on a fresh clone with the real tag history would have caught both issues immediately.
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.
Summary
Regression I introduced in #13. v1.4.1 and v1.4.2 release bodies contain every release since repo inception, concatenated. v1.4.0 (created before #13 landed) is clean.
What I broke
The old workflow's render step was:
When I consolidated cliff invocations in #13, I kept
--strip all(the whitespace handling) but lost `--latest` (the latest-release filter). The new flow:The render step happily produced the entire changelog history each time.
Why my local verification didn't catch it
When I tested the consolidation locally I rendered against a fresh clone with only ~3 tags — the output looked plausible at a glance and I didn't realize `--latest` was missing until v1.4.2's release page showed years of history in one body. Lesson: a fresh repo with few tags is a poor reproducer for "did I lose the filter."
Fix
One word: add `--latest` to the context-generation step.
Tried adding `--latest` to the `--from-context` step instead — silently ignored. Filtering has to happen at context generation time, not render time.
Verified locally
Only the bumped release. No history concatenation.
Cosmetic cleanup of already-broken releases (optional)
v1.4.1 and v1.4.2 release pages will continue to show the bloated bodies until manually corrected with
gh release edit v1.X.Y --notes-file <correct-notes>. Doable but optional — the releases themselves are valid (tags, assets, etc. are all fine); only the page text is wrong.Happy to do that cleanup as a follow-up if you want it tidied.
Test plan
--latest --bump --contextproduces single-release JSON.fix:so patch bump) has notes body containing ONLY this PR's bullet + the Full Changelog footer for v1.4.2 → v1.4.3. No older releases appear.