bug(cz_conventional_commits): changelog does not parse commits with pattern <type>!(<scope>): <message>

Description

When generating the changelog with a valid conventional commit message (eg: feat!(models): field x is now required), the bump MAJOR is detected properly, but the commit message is not parsed.

Steps to reproduce

1. Commit using feat!(models): field x is now required
2. Run cz -n cz_conventional_commits bump --changelog
3. Open CHANGELOG.md

Current behavior

The MAJOR version in incremented but the changelog shows an empty version eg:

## v1.0.0 (2021-05-06)

## v0.1.0 (2021-05-05)

### Feat

- add initial models for the poc

## v0.0.0 (2021-05-04)

This indicates that the commit was never parsed.

Desired behavior

The (valid) commit-message is parsed and added to the CHANGELOG.md as a breaking change.

Environment

• commitizen version: 2.17.4
• python version: 3.8.8
• operating system: Darwin (macOS 11.2.3)

Extra information

As a workaround I have defined my own PersonalCz(ConventionCommitsCz) class where I modified the commit_parser regex from defaults.commit_parser to r"^(?P<change_type>feat|fix|refactor|perf|BREAKING CHANGE)!?(?:\((?P<scope>[^()\r\n]*)\)|\()?(?P<breaking>!)?:\s(?P<message>.*)?" # noqa, which is nearly the same, I just added !? after named matching group change_type. This will not annotate the commit as a breaking change in the changelog, since the capturing group <breaking> is not found. But at least the commit will show up and the version is MAJOR bumped. Unfortunately a capturing group’s name should be unique, so I cannot just repeat the pattern to indicate the breaking change. I am still hacking away on the regex to see if I can make it match both valid messages feat!(models): field x i now required and feat(models)!: field x is now required. The latter already works out of the box

Also, what is the literal match on ( used for right after the | (boolean OR) in the default regex? It seems the be able to match something like feat(!: added this feature. Though the changelog will not find a BREAKING CHANGE here and just minor increment due to feat. cz check would also prevent us from making this commit message.

Additionally, I attempted to just use the working pattern as a commit-message (feat(models)!: field x is now required), but since I have a cz check in place, this is not allowed. So I feel like the commit_parser regex and schema_pattern are out of sync with each other. So then I used git commit --amend --no-verify (amended commit to use the “working pattern”) to circumvent the cz check and I ran cz -n cz_conventional_commits bump --changelog, which did result in a MAJOR bump, but no BREAKING CHANGE section in the changelog. This indicates that not only the commit_parser and schema_pattern are out of sync, but the component responsible for extracting the changelog (Fairly new to commitizen, so I haven’t found out where this behaviour is defined) is also not taking into account the ! to define a BREAKING CHANGE section.

[shifqu]

You do make sense. Since I am a ‘lazy’ dev who likes to type as little as possible, I just want to be able to run git commit -m "feat(models)!: field x is now required" and let the changelog be updated. Since the steps are clear on how to upgrade, I think we can indeed omit the (otherwise redundant) BREAKING CHANGE section.

Thanks for clarifying the idea of the BREAKING CHANGE section.

Opened #381 regarding the cz check as per your request.

closing this issue as I mainly misinterpreted some rules in conventional commits/usage of sections in changelog.

[woile]

Mmm not sure tbh, this seems like an edge case. As you said there’s no BREAKING CHANGE message showed. The idea of the BREAKING CHANGE subtitle, is to show to the user, what are the steps to “upgrade”, or inform what has been broken.

If there is no informative message, and we just show “BREAKING CHANGE”, it would be redundant, because the reader can see that you went from 0.1.0 to 1.0.0. Do I make any sense? haha

I just tested using the BREAKING CHANGE: block in the commits body, and it will only be rendered if there’s text following the :, otherwise, it won’t render the subtitle BREAKING CHANGE.

BTW the cz check does have a bug right? Do you mind opening a new bug for it?

thanks