-
-
Notifications
You must be signed in to change notification settings - Fork 301
adds a changelog tag parser to filter tags (--tag-parser; tag_parser) #537
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
Conversation
@hongkongkiwi sorry that it took some time to get back to making this PR.
Codecov Report
@@ Coverage Diff @@ ## master #537 +/- ## ========================================== + Coverage 97.92% 97.94% +0.02% ========================================== Files 39 39 Lines 1540 1557 +17 ========================================== + Hits 1508 1525 +17 Misses 32 32
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
...parser) The git tag parser is used to filter out undesired git tags from changelog. regex default is .* (all).
This new tag was added to a "feat:" rather than "bump:" commit.
The linter was complaining. Likely best to refactor this further.
Treats 'Unreleased' as if it is a git tag.
fff4d3b to
fbabc2a
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.
Should we rename line as filter_pattern or something similar to make it even more readable?
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.
Maybe we could renamed filtered as is_filtered. I'm also a bit confused when reading it.
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 the (, ) added by auto formatter? If not so, should we remove them?
Closes commitizen-tools#519 CLI flag name: --tag-regex Heavily inspired by commitizen-tools#537, but extends it with a smart default value to exclude non-release tags. This was suggested in commitizen-tools#519 (comment)
Closes commitizen-tools#519 CLI flag name: --tag-regex Heavily inspired by commitizen-tools#537, but extends it with a smart default value to exclude non-release tags. This was suggested in commitizen-tools#519 (comment)
Closes commitizen-tools#519 CLI flag name: --tag-regex Heavily inspired by commitizen-tools#537, but extends it with a smart default value to exclude non-release tags. This was suggested in commitizen-tools#519 (comment)
Uh oh!
There was an error while loading. Please reload this page.
Description
Some repositories have tags that are not matching the
bumpversion pattern (e.g.alpha/betarelease) #519.It makes sense to be able to filter those out. See this "Expected Behavior" section for an example.
The first commit:
Subsequent commits (probably best reviewing each commit individually):
if(by avoiding an optional).Checklist
./scripts/formatand./scripts/testlocally to ensure this change passes linter check and testExpected behavior
originally:
once filtered with
cz changelog --dry-run --tag-parser 'v[0-9]*\.[0-9]*\.[0-9]*'will be:Similar can be done with the
tomloption:tag_parser: "v[0-9]*\\.[0-9]*\\.[0-9]*". Notetomlrequired an extra\.Steps to Test This Pull Request
scripts/testIn the case below there is a filterable tag as the first commit.
Question:
v1.2.0-betatag:## v1.2.0-beta?## Unreleased?## Prerelease tag: v1.2.0-beta?Additional context
#519