Use named capture group in bump_pattern to enable stricter check

Goal
make regular expression pattern stricter so that we won't accidentally match things we don't need

Description
In commitizen/cz/conventional_commits/conventional_commits.py#L33 on command-changelog branch, I use named capture group so that we could use a stricter regular expression like .*\n\nBREAKING CHANGE. The benefit of it is that we don't have to break the whole commit message into lines like commitizem/bump.py#L31. It can also avoid bump or generate changelog based on commit message like fix --- it does not follow the rule but still match the pattern.
Another thought on this topic is that we probably merge the bump_map and bump_pattern into one some data class to store name(e.g., break), pattern(e.g., .*\n\nBREAKING CHANGE), behavior(e.g., PATCH).

Not sure how to follow with this one. do we still need it?

Would the dataclass be internal or it should be provided for templating?

The basic idea of the dataclass part is to make moving from dict to dataclass which might be clear.

The main idea of this issue is to use named capture group to make the regular expression stricter like how you implement commit_parser.

# now
bump_pattern = r"^(BREAKING[\-\ ]CHANGE|feat|fix|refactor|perf)(\(.+\))?(!)?"

# named capture group
bump_pattern = r"(?P<MAJOR>^.*\n\nBREAKING[-]CHANGE.*|)|(?P<MINOR>^feat.*)|?(P<PATCH>^fix.*|^perf.*|^refactor.*)"

Oh, I see, the find_increment would have to be completely refactored.

Still I see some complications, for conventional commits how would you capture BREAKING CHANGE and ! as breaking chagnes with a named group? I've tried a while ago with little success haha

Regarding the dataclasses I'd need an example to understand it better, for me a dict is usually clearer than anything, and can be easily converted to configuration if it's kept simple.

Still I see some complications, for conventional commits how would you capture BREAKING CHANGE and ! as breaking chagnes with a named group? I've tried a while ago with little success haha

Things like (?P<MAJOR>^.*\n\nBREAKING[-]CHANGE.*|)|(?P<MINOR>^feat.*), but not yet testesd.

Regarding the dataclasses I'd need an example to understand it better, for me a dict is usually clearer than anything, and can be easily converted to configuration if it's kept simple.

I'm working on this refactoring in #203 . (I've not yet get to the dataclass part.) IMO, dataclass is a stricter solution and less error-prone. It explicitly indicates the type of each configuration. I'll give you an example once I implement a prototype

I mean like these cases, how would we parse them? They both introduce breaking changes, and they'd use MAJOR as a group variable, right

refactor!: drop support for Python 2.7

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

It seems we do not need to parse the message when we bump the project version. All we want to know is which version (i.e. MAJOR, MINOR, PATCH) to bump. What we need to know if whether these types (e.g., MAJOR, MINOR, PATCH) of commits exist.

Any update on this?

not at this moment 😢

feat(bump_rule): add BumpRule, VersionIncrement, Prerelease Enum

Navigation Menu

Repository navigation

Use named capture group in bump_pattern to enable stricter check #129

8 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Use named capture group in bump_pattern to enable stricter check #129

Description

Activity

woile commented on Jun 26, 2020

Lee-W commented on Jun 26, 2020

woile commented on Jun 27, 2020

Lee-W commented on Jun 27, 2020

woile commented on Jun 27, 2020

Lee-W commented on Jun 28, 2020

woile commented on Apr 28, 2023

Lee-W commented on Jun 14, 2023

8 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions