-
-
Notifications
You must be signed in to change notification settings - Fork 266
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(changelog): handle custom tag_format in changelog generation #995
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #995 +/- ##
==========================================
+ Coverage 97.33% 97.63% +0.29%
==========================================
Files 42 55 +13
Lines 2104 2575 +471
==========================================
+ Hits 2048 2514 +466
- Misses 56 61 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
You can add tests similar to this: |
I have taken a stab at the test case. |
commitizen/commands/changelog.py
Outdated
latest_tag_version: str = bump.normalize_tag( | ||
changelog_meta.latest_version, | ||
tag_format=self.tag_format, | ||
scheme=self.scheme, | ||
) | ||
start_rev = self._find_incremental_rev( | ||
strip_local_version(latest_tag_version), tags | ||
strip_local_version(changelog_meta.latest_version), tags | ||
) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello,
Removing this logic is breaking the search for custom tags (with a tag-format like example-${version}
).
The first bump (with --changelog
option) will have no problem and it will create the CHANGELOG.md
file but any bump afterward will result in an error: commitizen.exceptions.NoRevisionError: No tag found to do an incremental changelog
.
This is due to the _find_incremental_rev
function that look at similarity between a given tag and the tags list. But without the normalization, it calculates similarity between a stripped tag (without any format so like 0.1.1
) and the formatted tag (like example-0.1.0
) resulting in a similarity below threshold.
So, except if you have another edge case justifying this removal, I think it should be kept.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
Thanks for the feedback, I'll put this to a draft status and try to find a solution that doesn't break the current way of working. My gut feeling is it might need an additional flag maybe something like --strict-tag-matching
what are your thoughts on taking that approach?
I guess the fact you found that error might mean there is a missing test case, I will try adding that first to replicate the error with my changes so I have something to validate against.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used your version with a revert on the selected part (here), and it seems to works pretty damn well for me, that's why I was asking for the "why" of the change.
I was able to bump and generate for multiple cz.toml file and multiple tag-format (in a monorepo with 3 sub-packages).
The normalizing part was introduced by that PR, exactly fixing the error I got.
I really think that you just need to keep the normalizing part, and we should be OK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
Thanks for clarifying I misunderstood your point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a test that shows the failure you describe with my approach.
However, when I update my test to then do a second commit/bump then I start to get a failure as the changelog_meta.latest_version
for my scenario where the custom tag values comes after the version number is returned as 0.2.0custom (str) which then causes an Invalid version error from the call to scheme in the bump.normalize_tag function.
I found that the change log is written with tag_format in the title for each section but then parse_version_from_title
uses the parser from the version schema which means that when the tag format has a suffix rather than a prefix the issue occurs.
I will try to investigate further but would value your thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there anything that needs clarification for this one? (I guess not?) or should I start reviewing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just want to check the way I have handled the different possible tag_formats in markdown.py seems OK. If it is I will make the appropriate changes to the other formats taking the same approach. Once I have completed that it will be ready for review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any major flaws at first glance, but I will try to take a deeper look this weekend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry it took a while for me to get this finished off. Ready for review when you have time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I was not able to review it last week. 😞 Let's see whether I can at least check a portion of it this week. 💪
0cc5cef
to
7d74d80
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems good but:
TAG_FORMAT_REGEXS
should be factorized and declared once- the new
${}
syntax should be documented
commitizen/changelog_formats/base.py
Outdated
TAG_FORMAT_REGEXS = { | ||
"$version": version_regex, | ||
"$major": r"(?P<major>\d+)", | ||
"$minor": r"(?P<minor>\d+)", | ||
"$patch": r"(?P<patch>\d+)", | ||
"$prerelease": r"(?P<prerelease>\w+\d+)?", | ||
"$devrelease": r"(?P<devrelease>\.dev\d+)?", | ||
"${version}": version_regex, | ||
"${major}": r"(?P<major>\d+)", | ||
"${minor}": r"(?P<minor>\d+)", | ||
"${patch}": r"(?P<patch>\d+)", | ||
"${prerelease}": r"(?P<prerelease>\w+\d+)?", | ||
"${devrelease}": r"(?P<devrelease>\.dev\d+)?", | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those are exactly the same as in changelog:get_version_tag
so I suggest to factorize this into a public factory, something like:
TAG_FORMAT_REGEXS = {
"$major": r"(?P<major>\d+)",
"$minor": r"(?P<minor>\d+)",
"$patch": r"(?P<patch>\d+)",
"$prerelease": r"(?P<prerelease>\w+\d+)?",
"$devrelease": r"(?P<devrelease>\.dev\d+)?",
"${version}": version_regex,
"${major}": r"(?P<major>\d+)",
"${minor}": r"(?P<minor>\d+)",
"${patch}": r"(?P<patch>\d+)",
"${prerelease}": r"(?P<prerelease>\w+\d+)?",
"${devrelease}": r"(?P<devrelease>\.dev\d+)?",
}
def tag_format_regexps_for(version: Pattern) -> dict[str, Pattern]:
return {
"$version": version,
"${version}": version,
**TAG_FORMAT_REGEXS
}
This way:
- single source of thrust
- custom format implementations can reuse
TAG_FORMAT_REGEXS
andtag_format_regexps_for
commitizen/providers/scm_provider.py
Outdated
"${version}": r"(?P<version>.+)", | ||
"${major}": r"(?P<major>\d+)", | ||
"${minor}": r"(?P<minor>\d+)", | ||
"${patch}": r"(?P<patch>\d+)", | ||
"${prerelease}": r"(?P<prerelease>\w+\d+)?", | ||
"${devrelease}": r"(?P<devrelease>\.dev\d+)?", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a new accepted syntax.
Documentation and conventional commit message should reflect that
commitizen/providers/scm_provider.py
Outdated
"${minor}": r"(?P<minor>\d+)", | ||
"${patch}": r"(?P<patch>\d+)", | ||
"${prerelease}": r"(?P<prerelease>\w+\d+)?", | ||
"${devrelease}": r"(?P<devrelease>\.dev\d+)?", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very similar to the 2 previous factorizable TAG_FORMAT_REGEXS
so I think it should be factorized too,
I think I have implemented the suggestions |
commitizen/defaults.py
Outdated
@@ -133,3 +133,20 @@ class Settings(TypedDict, total=False): | |||
) | |||
change_type_order = ["BREAKING CHANGE", "Feat", "Fix", "Refactor", "Perf"] | |||
bump_message = "bump: version $current_version → $new_version" | |||
|
|||
|
|||
def get_tag_regexes(version_regex: str) -> dict[str | Any, str | Any]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When will the key return Any
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
We probably need to resolve the conflict as well 👀 . We're now using screenshots as part of our doc. you can generate the latest screenshot through |
No worries on the time taken, I will address all the points but might take me a week due to other commitments |
Hi @Lee-W, I have attempted to address the comments, please validate when you have time. When attempting to run the I'm not sure if you are already aware, but with the push hook in place I got an error for a commit not in my PR commit validation: failed!
please enter a commit message in the commitizen format.
commit "37522866e4788deb12b2ef1c426662400b0ebac8": "docs(cli/screenshots) update CLI screenshots"
pattern: (?s)(build|ci|docs|feat|fix|perf|refactor|style|test|chore|revert|bump)(\(\S+\))?!?:( [^\n\r]+)((\n\n.*)|(\s*))?$ |
The screenshot doesn't look like an error to me 🤔 so basically, this is a command we use to generate the latest cz help message. so if the screenshots are generated, I think we are good 🙂
Even if you try with rebase? There was one commit with an ill-formatted message. But our hook should only check the commits in this branch, I think 🤔 It Looks like the CI is passing now. Is this still an issue? |
Maybe my PR didn't need any changes to the generated images, possibly just confusion on my side. I have just made sure my fork is updated and as I have no changes I just tried running the hook
Doing some further investigation my fork doesn't have origin/HEAD set. After running
The hook now works :) |
Niiiiiiice! I will probably not be around for half a month, but I will try to take a look after I'm back from traveling. Thanks for actively helping out. |
Sorry for the looong absence. |
This could potentially fix #1149 right? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM @Lee-W @noirbizarre any thoughts?
When the tag_format does not follow the allowed schemas patterns then changlog generation fails.
Co-authored-by: Wei Lee <[email protected]>
I'm planning on merging this tomorrow |
I'll be almost out till mid-Oct 😞 @woile Thanks for taking care of this! |
When the tag_format does not follow the allowed schemas patterns then changlog generation fails.
Description
I am working in a mono repo with multiple
.cz.toml
configs (one per component) usingtag_format
to create tags for each component so they can be released independent of each other. When trying to generate the changelog for each component errors are generated see #845.I was unsure how to add a test case for this if you have ideas please let me know and I will be happy to add.
Checklist
./scripts/format
and./scripts/test
locally to ensure this change passes linter check and testExpected behavior
changelogs will now be generated correctly when running
cz bump --changelog
Steps to Test This Pull Request