Skip to content
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

Enable cover cz_conventional_commits via [tool.commitizen.customize] #1270

Open
AtticusZeller opened this issue Oct 22, 2024 · 8 comments
Open

Comments

@AtticusZeller
Copy link

AtticusZeller commented Oct 22, 2024

Description

hey there👋 it's a fantastic cil tools. thanks for your guys contribution!

it's impossible to cover the default options such as commit Patten via toml after checking the docs and raw code,only will work on complicated full customization in toml which is scary.
😭

the following is the version i would like to use:

[tool.commitizen]
name = "cz_conventional_commits"
tag_format = "$version"
version_scheme = "semver"
version_provider = "pep621"
update_changelog_on_bump = true
major_version_zero = true
changelog_incremental = false

[tool.commitizen.customize]
commit_parser = "^((?P<change_type>feat|fix|refactor|perf|docs|style|refactor|BREAKING CHANGE)(?:\\((?P<scope>[^()\r\n]*)\\)|\\()?(?P<breaking>!)?|\\w+!):\\s(?P<message>.*)?"
changelog_pattern = "^((BREAKING[\\-\\ ]CHANGE|\\w+)(\\(.+\\))?!?):"
change_type_map = {"feat"="Feat","fix"="Fix","refactor"= "Refactor","perf"="Perf","docs"="Docs","style"="Style"}

of course,[tool.commitizen.customize] would be invalid because of [tool.commitizen] name is not cz_customize according to the docs and raw code.

it looks like we coverd cz_conventional_commits version with [tool.commitizen.customize],which is what we need.

so let's replace the name as cz_customize, it will work on cz bump --dry-run,but cz commit -a would failed for no complete definition [tool.commitizen.customize],also docs had given the complete one looks terrified.

Possible Solution

i think we can realize it via making class CustomizeCommitsCz:to inherit from ConventionalCommitsCz directly.

@woile
Copy link
Member

woile commented Oct 22, 2024

Needs more information and examples. I don't understand what have you tried to do

@AtticusZeller
Copy link
Author

sorry for lack of enough context.

in short,I found that the changelog did not include total commit records(only fix feat etc)

i wanna simply keep the current configuration and cover the attr that defines which commit should be involved in changelog with toml extra config

given official config and then cover it,but now we can not cover a bit custom config with toml until the complete custom config In toml

hope it will clarify my feature request.😄

@AtticusZeller AtticusZeller changed the title Enable toml cover custom settings Enable toml cover partial custom settings Oct 23, 2024
@woile
Copy link
Member

woile commented Oct 23, 2024

But what did you already do? Can you share the toml that didn't work?
This is a very common case and it's documented here:
https://commitizen-tools.github.io/commitizen/customization/#1-customize-in-configuration-file

commit_parser = "^(?P<change_type>feature|bug fix):\\s(?P<message>.*)?"
changelog_pattern = "^(feature|bug fix)?(!)?"
change_type_map = {"feature" = "Feat", "bug fix" = "Fix"}

@AtticusZeller AtticusZeller changed the title Enable toml cover partial custom settings Enable cover cz_conventional_commits via [tool.commitizen.customize] Oct 23, 2024
@AtticusZeller
Copy link
Author

AtticusZeller commented Oct 23, 2024

all finished but docs in #1274!

@AtticusZeller
Copy link
Author

if you guys find it really different to customize, I recommend git-cliff or git-changelog.

it would help a lot😊

@woile woile reopened this Nov 28, 2024
@woile
Copy link
Member

woile commented Nov 28, 2024

I think we should continue with this. It makes sense to allow the modification of an existing provider.
Right @Lee-W @noirbizarre ?

@woile
Copy link
Member

woile commented Nov 28, 2024

Maybe instead of breaking tool.commitizen.customize we could create a new one: tool.commitizen.rules.
Which would override the existing commitizen definition:

[tool.commitizen.rules]
commit_parser = "^((?P<change_type>feat|fix|refactor|perf|docs|style|refactor|ci|BREAKING CHANGE)(?:\\((?P<scope>[^()\r\n]*)\\)|\\()?(?P<breaking>!)?|\\w+!):\\s(?P<message>.*)?"
changelog_pattern = "^((BREAKING[\\-\\ ]CHANGE|\\w+)(\\(.+\\))?!?):"
change_type_map = {"feat"="Feat","fix"="Fix","refactor"= "Refactor","perf"="Perf","docs"="Docs","style"="Style","ci"="CI"}

Thoughts?

@Lee-W
Copy link
Member

Lee-W commented Nov 28, 2024

Yep, I think we should do it. We probably could make the rule a column of tool.commitizen.customize? If not provided, then it'll work as it is now. If provided, it'll inherit from that cz rule. Might need to do some import or class magic for this, but probably worth exploring 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants