Customizing commitizen is not hard at all. We have two different ways to do so.
The basic steps are:
- Define your custom committing or bumping rules in the configuration file.
- Declare
name = "cz_customize"in your configuration file, or add-n cz_customizewhen running commitizen.
Example:
[tool.commitizen]
name = "cz_customize"
[tool.commitizen.customize]
message_template = "{{change_type}}:{% if show_message %} {{message}}{% endif %}"example = "feature: this feature enable customize through config file"schema = "<type>: <body>"schema_pattern = "(feature|bug fix):(\\s.*)"bump_pattern = "^(break|new|fix|hotfix)"bump_map = {"break" = "MAJOR", "new" = "MINOR", "fix" = "PATCH", "hotfix" = "PATCH"}
change_type_order = ["BREAKING CHANGE", "feat", "fix", "refactor", "perf"]
info_path = "cz_customize_info.txt"info = """This is customized info"""commit_parser = "^(?P<change_type>feature|bug fix):\\s(?P<message>.*)?"changelog_pattern = "^(feature|bug fix)?(!)?"change_type_map = {"feature" = "Feat", "bug fix" = "Fix"}
[[tool.commitizen.customize.questions]]
type = "list"name = "change_type"choices = [{value = "feature", name = "feature: A new feature."}, {value = "bug fix", name = "bug fix: A bug fix."}]
# choices = ["feature", "fix"] # short versionmessage = "Select the type of change you are committing"
[[tool.commitizen.customize.questions]]
type = "input"name = "message"message = "Body."
[[tool.commitizen.customize.questions]]
type = "confirm"name = "show_message"message = "Do you want to add body message in commit?"The equivalent example for a json config file:
{
"commitizen": {
"name": "cz_customize",
"customize": {
"message_template": "{{change_type}}:{% if show_message %} {{message}}{% endif %}",
"example": "feature: this feature enable customize through config file",
"schema": "<type>: <body>",
"schema_pattern": "(feature|bug fix):(\\s.*)",
"bump_pattern": "^(break|new|fix|hotfix)",
"bump_map": {
"break": "MAJOR",
"new": "MINOR",
"fix": "PATCH",
"hotfix": "PATCH"
},
"change_type_order": ["BREAKING CHANGE", "feat", "fix", "refactor", "perf"],
"info_path": "cz_customize_info.txt",
"info": "This is customized info",
"commit_parser": "^(?P<change_type>feature|bug fix):\\s(?P<message>.*)?",
"changelog_pattern": "^(feature|bug fix)?(!)?",
"change_type_map": {"feature": "Feat", "bug fix": "Fix"},
"questions": [
{
"type": "list",
"name": "change_type",
"choices": [
{
"value": "feature",
"name": "feature: A new feature."
},
{
"value": "bug fix",
"name": "bug fix: A bug fix."
}
],
"message": "Select the type of change you are committing"
},
{
"type": "input",
"name": "message",
"message": "Body."
},
{
"type": "confirm",
"name": "show_message",
"message": "Do you want to add body message in commit?"
}
]
}
}
}And the correspondent example for a yaml json file:
commitizen:
name: cz_customizecustomize:
message_template: "{{change_type}}:{% if show_message %} {{message}}{% endif %}"example: 'feature: this feature enable customize through config file'schema: "<type>: <body>"schema_pattern: "(feature|bug fix):(\\s.*)"bump_pattern: "^(break|new|fix|hotfix)"commit_parser: "^(?P<change_type>feature|bug fix):\\s(?P<message>.*)?",changelog_pattern: "^(feature|bug fix)?(!)?",change_type_map:
feature: Featbug fix: Fixbump_map:
break: MAJORnew: MINORfix: PATCHhotfix: PATCHchange_type_order: ["BREAKING CHANGE", "feat", "fix", "refactor", "perf"]info_path: cz_customize_info.txtinfo: This is customized infoquestions:
- type: listname: change_typechoices:
- value: featurename: 'feature: A new feature.'
- value: bug fixname: 'bug fix: A bug fix.'message: Select the type of change you are committing
- type: inputname: messagemessage: Body.
- type: confirmname: show_messagemessage: Do you want to add body message in commit?| Parameter | Type | Default | Description |
|---|---|---|---|
questions | Questions | None | Questions regarding the commit message. Detailed below. The type Questions is an alias to Iterable[MutableMapping[str, Any]] which is defined in commitizen.defaults. It expects a list of dictionaries. |
message_template | str | None | The template for generating message from the given answers. message_template should either follow Jinja2 formatting specification, and all the variables in this template should be defined in name in questions |
example | str | None | (OPTIONAL) Provide an example to help understand the style. Used by cz example. |
schema | str | None | (OPTIONAL) Show the schema used. Used by cz schema. |
schema_pattern | str | None | (OPTIONAL) The regular expression used to do commit message validation. Used by cz check. |
info_path | str | None | (OPTIONAL) The path to the file that contains explanation of the commit rules. Used by cz info. If not provided cz info, will load info instead. |
info | str | None | (OPTIONAL) Explanation of the commit rules. Used by cz info. |
bump_map | dict | None | (OPTIONAL) Dictionary mapping the extracted information to a SemVer increment type (MAJOR, MINOR, PATCH) |
bump_pattern | str | None | (OPTIONAL) Regex to extract information from commit (subject and body) |
change_type_order | str | None | (OPTIONAL) List of strings used to order the Changelog. All other types will be sorted alphabetically. Default is ["BREAKING CHANGE", "Feat", "Fix", "Refactor", "Perf"] |
commit_parser | str | None | (OPTIONAL) Regex to extract information used in creating changelog. See more |
changelog_pattern | str | None | (OPTIONAL) Regex to understand which commits to include in the changelog |
change_type_map | dict | None | (OPTIONAL) Dictionary mapping the type of the commit to a changelog entry |
| Parameter | Type | Default | Description |
|---|---|---|---|
type | str | None | The type of questions. Valid type: list, input and etc. [See More][different-question-types] |
name | str | None | The key for the value answered by user. It's used in message_template |
message | str | None | Detail description for the question. |
choices | list | None | (OPTIONAL) The choices when type = list. Either use a list of values or a list of dictionaries with name and value keys. Keyboard shortcuts can be defined via key. See examples above. |
default | Any | None | (OPTIONAL) The default value for this question. |
filter | str | None | (Optional) Validator for user's answer. (Work in Progress) |
| [different-question-types]: https://github.com/tmbo/questionary#different-question-types |
When the use_shortcuts config option is enabled, commitizen can show and use keyboard shortcuts to select items from lists directly.
For example, when using the cz_conventional_commits commitizen template, shortcut keys are shown when selecting the commit type. Unless otherwise defined, keyboard shortcuts will be numbered automatically.
To specify keyboard shortcuts for your custom choices, provide the shortcut using the key parameter in dictionary form for each choice you would like to customize.
The basic steps are:
- Inheriting from
BaseCommitizen - Give a name to your rules.
- Create a python package using
setup.py,poetry, etc - Expose the class as a
commitizen.pluginentrypoint
Check an example on how to configure BaseCommitizen.
You can also automate the steps above through cookiecutter.
cookiecutter gh:commitizen-tools/commitizen_cz_templateSee commitizen_cz_template for details.
Once you publish your rules, you can send us a PR to the Third-party section.
Create a Python module, for example cz_jira.py.
Inherit from BaseCommitizen, and you must define questions and message. The others are optional.
fromcommitizen.cz.baseimportBaseCommitizenfromcommitizen.defaultsimportQuestionsclassJiraCz(BaseCommitizen):
# Questions = Iterable[MutableMapping[str, Any]]# It expects a list with dictionaries.defquestions(self) ->Questions:
"""Questions regarding the commit message."""questions= [
{"type": "input", "name": "title", "message": "Commit title"},
{"type": "input", "name": "issue", "message": "Jira Issue number:"},
]
returnquestionsdefmessage(self, answers: dict) ->str:
"""Generate the message with the given answers."""return"{0} (#{1})".format(answers["title"], answers["issue"])
defexample(self) ->str:
"""Provide an example to help understand the style (OPTIONAL) Used by `cz example`. """return"Problem with user (#321)"defschema(self) ->str:
"""Show the schema used (OPTIONAL) Used by `cz schema`. """return"<title> (<issue>)"definfo(self) ->str:
"""Explanation of the commit rules. (OPTIONAL) Used by `cz info`. """return"We use this because is useful"The next file required is setup.py modified from flask version.
fromsetuptoolsimportsetupsetup(
name="JiraCommitizen",
version="0.1.0",
py_modules=["cz_jira"],
license="MIT",
long_description="this is a long description",
install_requires=["commitizen"],
entry_points={"commitizen.plugin": ["cz_jira = cz_jira:JiraCz"]},
)So in the end, we would have
.
├── cz_jira.py
└── setup.py
And that's it. You can install it without uploading to pypi by simply
doing pip install .
If you feel like it should be part of this repo, create a PR.
You need to define 2 parameters inside your custom BaseCommitizen.
| Parameter | Type | Default | Description |
|---|---|---|---|
bump_pattern | str | None | Regex to extract information from commit (subject and body) |
bump_map | dict | None | Dictionary mapping the extracted information to a SemVer increment type (MAJOR, MINOR, PATCH) |
Let's see an example.
fromcommitizen.cz.baseimportBaseCommitizenclassStrangeCommitizen(BaseCommitizen):
bump_pattern=r"^(break|new|fix|hotfix)"bump_map= {"break": "MAJOR", "new": "MINOR", "fix": "PATCH", "hotfix": "PATCH"}That's it, your commitizen now supports custom rules, and you can run.
cz -n cz_strange bumpThe changelog generator should just work in a very basic manner without touching anything.
You can customize it of course, and this are the variables you need to add to your custom BaseCommitizen.
| Parameter | Type | Required | Description |
|---|---|---|---|
commit_parser | str | NO | Regex which should provide the variables explained in the changelog description |
changelog_pattern | str | NO | Regex to validate the commits, this is useful to skip commits that don't meet your ruling standards like a Merge. Usually the same as bump_pattern |
change_type_map | dict | NO | Convert the title of the change type that will appear in the changelog, if a value is not found, the original will be provided |
changelog_message_builder_hook | method: (dict, git.GitCommit) -> dict | NO | Customize with extra information your message output, like adding links, this function is executed per parsed commit. Each GitCommit contains the following attrs: rev, title, body, author, author_email |
changelog_hook | method: (full_changelog: str, partial_changelog: Optional[str]) -> str | NO | Receives the whole and partial (if used incremental) changelog. Useful to send slack messages or notify a compliance department. Must return the full_changelog |
fromcommitizen.cz.baseimportBaseCommitizenimportchatimportcomplianceclassStrangeCommitizen(BaseCommitizen):
changelog_pattern=r"^(break|new|fix|hotfix)"commit_parser=r"^(?P<change_type>feat|fix|refactor|perf|BREAKING CHANGE)(?:\((?P<scope>[^()\r\n]*)\)|\()?(?P<breaking>!)?:\s(?P<message>.*)?"change_type_map= {
"feat": "Features",
"fix": "Bug Fixes",
"refactor": "Code Refactor",
"perf": "Performance improvements",
}
defchangelog_message_builder_hook(
self, parsed_message: dict, commit: git.GitCommit
) ->dict:
rev=commit.revm=parsed_message["message"]
parsed_message[
"message"
] =f"{m}{rev} [{commit.author}]({commit.author_email})"returnparsed_messagedefchangelog_hook(
self, full_changelog: str, partial_changelog: Optional[str]
) ->str:
"""Executed at the end of the changelog generation full_changelog: it's the output about to being written into the file partial_changelog: it's the new stuff, this is useful to send slack messages or similar Return: the new updated full_changelog """ifpartial_changelog:
chat.room("#committers").notify(partial_changelog)
iffull_changelog:
compliance.send(full_changelog)
full_changelog.replace(" fix ", " **fix** ")
returnfull_changelogIf you want commitizen to catch your exception and print the message, you'll have to inherit CzException.
fromcommitizen.cz.exceptionimportCzExceptionclassNoSubjectProvidedException(CzException):
...Commitizen migrated to a new plugin format relying on importlib.metadata.EntryPoint.
Migration should be straight-forward for legacy plugins:
- Remove the
discover_thisline from you plugin module - Expose the plugin class under as a
commitizen.pluginentrypoint.
The name of the plugin is now determined by the name of the entrypoint.
If you were having a CzPlugin class in a cz_plugin.py module like this:
fromcommitizen.cz.baseimportBaseCommitizenclassPluginCz(BaseCommitizen):
...
discover_this=PluginCzThen remove the discover_this line:
fromcommitizen.cz.baseimportBaseCommitizenclassPluginCz(BaseCommitizen):
...and expose the class as entrypoint in you setuptools:
fromsetuptoolsimportsetupsetup(
name="MyPlugin",
version="0.1.0",
py_modules=["cz_plugin"],
entry_points={"commitizen.plugin": ["plugin = cz_plugin:PluginCz"]},
...,
)Then your plugin will be available under the name plugin.