fix(changelog): skip unreachable tags when picking previous release (#2083) - #2085
fix(changelog): skip unreachable tags when picking previous release (#2083)#2085nehraa wants to merge 1 commit into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #2085 +/- ##
==========================================
+ Coverage 98.19% 98.26% +0.07%
==========================================
Files 61 61
Lines 2829 2832 +3
==========================================
+ Hits 2778 2783 +5
+ Misses 51 49 -2 ☔ View full report in Codecov by Harness. |
There was a problem hiding this comment.
🟡 Changes recommended
Explicit version-range handling remains affected, and the regression test and documentation nits need updates.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Fixes changelog previous-release selection by excluding unreachable parallel-branch tags.
Changes:
- Filters changelog tags by reachability from
HEAD. - Adds regression coverage for parallel maintenance branches.
File summaries
| File | Summary |
|---|---|
commitizen/commands/changelog.py |
Adds reachability filtering. Moderate (1 vote): this also breaks explicit version ranges on other branches and needs narrower handling. |
tests/commands/test_changelog_command.py |
Adds regression setup. Nits (3 votes each): exercise the command path directly and add the required nested-function docstring. |
Review details
Suppressed comments (1)
commitizen/commands/changelog.py:214
- Using
--mergedhere also filters the tags needed to resolve an explicit positional range.get_oldest_and_newest_revlooks up both versions fromtags, socz changelog 4.11.0..4.12.0run while HEAD is on another release branch will now raiseNoCommitsFoundError, even though the documented command supports version ranges and Git can read those refs. Restrict reachability filtering to implicit previous-release lookup, or resolve explicit ranges against their requested end revision.
tags = self.tag_rules.get_version_tags(
git.get_tags(reachable_only=True), warn=True
)
- Files reviewed: 2/2 changed files
- Comments generated: 2
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| # env afterward so subsequent ``util.tick`` keeps working. | ||
| from commitizen import cmd as _cmd | ||
|
|
||
| def _tag_at(tag, iso_date): |
There was a problem hiding this comment.
Fixed: added docstring to _tag_at in the amended commit.
| start_rev, end_rev = get_oldest_and_newest_rev( | ||
| cz_git.get_tags(reachable_only=True), "5.4.0", rules |
There was a problem hiding this comment.
Fixed in the amended commit. The test now goes through util.run_cli (cz changelog) and uses monkeypatch to spy on the production call site commitizen.commands.changelog.git.get_tags. If the production change is reverted, the spy assertion fails because the call no longer passes reachable_only=True.
46c82fc to
828393f
Compare
`cz changelog <version>` resolves the previous-release tag by walking the creatordate-sorted tag list. When a parallel maintenance branch carries a tag whose creatordate sits between the current release and the legitimate previous release, that branch's tag was wrongly picked because it was reachable from some commit, just not from HEAD. `get_tags()` already supports a `reachable_only` flag that appends `git tag --merged`. Pass it from the changelog path so unreachable parallel-line tags are filtered out before the sort, mirroring the behaviour of `get_latest_tag_name()` which already uses `git describe --abbrev=0 --tags` (ancestry-based) for the same reason. Fixes commitizen-tools#2083
828393f to
429973b
Compare
|
Suppressed comment addressed: the reachability filter is now scoped to the implicit previous-release lookup path only. Explicit Added |
Description
cz changelog <version>resolves the previous-release tag by walking the creatordate-sorted tag list. When a parallel maintenance branch carries a tag with a creatordate between the current release and the legitimate previous release, that branch's tag was wrongly picked — it was reachable from some commit, just not from HEAD.get_tags()already supports areachable_onlyflag that appendsgit tag --merged. This change passes that flag from the changelog path so unreachable parallel-line tags are filtered out before the sort, matching the behaviour ofget_latest_tag_name(), which already usesgit describe --abbrev=0 --tags(ancestry-based) for the same reason.Repro (espressif/esptool from the issue body): a parallel
v4line carried4.12.0whose creatordate was between5.3.1and5.4.0.cz changelog 5.4.0resolved the previous-release tag to4.12.0instead of5.3.1, then generated notes from4.12.0to5.4.0becauseget_next_tag_name_after_versionwalks the date-sorted list and4.12.0sits next to5.4.0.Fixes #2083
Checklist
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code following the guidelines
Code Changes
uv run poe alllocally to ensure this change passes linter check and testsDocumentation Changes