fix(changelog): point version links at the per-crate tags that exist - #216
Merged
Merged
Conversation
Every version heading in every generated CHANGELOG.md linked to
/releases/tag/<bare semver> — e.g. /releases/tag/0.4.2. No such tag
exists, and none ever has: all 191 tags in this repo are per-crate
prefixed (resq-cli-v0.4.2, resq-tui-v0.1.13, ...), because release-plz
tags multi-package workspaces with its default git_tag_name template,
`{{ package }}-v{{ version }}`, and this repo does not override it. So
every link in every per-crate changelog was dead.
release-plz always injects `package` (the cargo package name) into the
git-cliff template context — unconditionally, via add_package_context in
its single changelog construction path — so the heading can reproduce
the real tag as `{{ package }}-v{{ version }}`. Verified against
release-plz's documented changelog context and against the pinned
release-plz 0.3.168 source, not assumed.
Dropped the no-op `trim_start_matches(pat="v")` on the display text at
the same time: release-plz passes `version` as a bare semver, so the
filter never matched anything, and leaving it would have had the two
halves of the line disagree about whether `version` carries a `v`.
`tag_pattern` is inert here — release-plz builds the release itself and
calls git-cliff's changelog API, which never reads it; only the
git-cliff CLI's repo scan does. Corrected rather than removed so it
describes the tag scheme in use, with a comment recording that it has no
effect on what this repo ships.
The existing CHANGELOG.md files are left alone; release-plz rewrites
each heading as it cuts the next release for that crate.
|
Understand this PR’s impact Explore downstream dependencies and potential security impact with Blast Radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe changelog configuration now links release headings to full crate-prefixed version tags. Its tag pattern matches lowercase alphanumeric or hyphenated package names followed by ChangesChangelog tag alignment
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Bug fix 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
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.
The defect
Every version link in every generated changelog 404s.
cliff.tomlrendered the heading as/releases/tag/{{ version }}, which emitshttps://github.com/resq-software/crates/releases/tag/0.4.2. There is no bare0.4.2tag and there never has been — all 191 tags in this repo areper-crate prefixed (
resq-cli-v0.4.2,resq-tui-v0.1.13, …):That scheme is not incidental: release-plz tags multi-package workspaces with
its default
git_tag_nametemplate,{{ package }}-v{{ version }}, andrelease-plz.tomldoes not override it.The fix
packageis not a guess. release-plz injects it into the git-cliff templatecontext unconditionally, in the one place it ever constructs a changelog
(
release_plz_core::changelog::Changelog::get_changelog→add_package_context→add_context("package", package)), and that value ispackage.name— the cargo package name. It is also documented in release-plz'schangelog-context reference (
"package": "my_crate"). Both checked against therelease-plz version this repo actually pins (
release-plz-actionv0.5.138 →release-plz
0.3.168), not against latest.The no-op
trim_start_matches(pat="v")goes at the same time. release-plzpasses
versionas a bare semver (next_version.to_string()on asemver::Version), so the filter never matched; keeping it would have left thetwo halves of the line disagreeing about whether
versioncarries av.tag_patterntag_pattern = "v[0-9].*"did not describe the scheme either. It is alsoinert: release-plz builds the
Releaseitself and calls git-cliff'schangelog API directly, and
tag_patternis never read on that path — ingit-cliff-coreit appears only as a config struct field, never inchangelog.rs. Only the git-cliff CLI's repo scan(
repo.tags(&config.git.tag_pattern, …)) consumes it.Corrected rather than removed, with a comment recording that it has no effect
on what this repo ships. Removing it would have been defensible too, but the
old value was only accidentally right — git-cliff matches
tag_patternunanchored, so
v[0-9].*happened to matchresq-cli-v0.4.2via the embeddedv0. An anchored pattern that actually describes<crate>-v<semver>cannotsilently select the wrong subset if that ever starts being read.
Proof
Rendered through release-plz's exact code path —
git-cliff-corepinned to=2.14.1(the version in release-plz v0.3.168's lockfile),default-features = falseas release-plz sets it,Config::load("cliff.toml"), release-plz'sdefault PR-link
commit_preprocessorinjected the way release-plz injects itwhen the user config leaves
commit_preprocessorsempty, thenChangelog::new(...)+add_context("package", "resq-cli").Before — the harness reproduces the committed changelog byte for byte,
confirming it is faithful:
which is character-identical to the heading in
crates/resq-cli/CHANGELOG.md.After:
The rendered URL resolves — tag extracted from the generated link, not typed
by hand:
The GitHub Release's own
html_urlis identical to what the template nowrenders.
Scope
Template only. The existing
CHANGELOG.mdfiles are deliberately untouched —release-plz rewrites each heading as it cuts the next release for that crate,
and regenerating 18 crates' history here would bury this one-line fix.
Not fixed here, worth separate issues
CHANGELOG.mdis a hand-written stub claiming## [0.2.0] - 2026-03-14with a single bullet about CI workflows, while
[workspace.package]inCargo.tomlis at0.1.22. Nothing generates or maintains it.crates/resq-cli/CHANGELOG.mdis structurally corrupt — three stacked# Changelogheaders (lines 1, 21, 126), and[0.4.1]appears twice at twodifferent dates (2026-08-31 and 2026-08-24).
commit.github.pr_number, but release-plz buildsgit-cliff-corewithdefault-features = false, so thegithubfeature is off andcommit.githubis never populated. PR links reach the changelog only through release-plz's
default
commit_preprocessor, which rewrites a trailing(#123)into amarkdown link — visible in the render above. Harmless (Tera treats the
missing path as falsy in
{% if %}), but misleading to anyone editing thetemplate. The equivalent under release-plz is
commit.remote.pr_number.Summary by CodeRabbit