Customization
Customizing commitizen is not hard at all. We have two different ways to do so.
1. Customize in configuration file¶
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_customize
when 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 version
message = "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_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)"
commit_parser: "^(?P<change_type>feature|bug fix):\\s(?P<message>.*)?",
changelog_pattern: "^(feature|bug fix)?(!)?",
change_type_map:
feature: Feat
bug fix: Fix
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
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?
Customize configuration¶
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 |
Detailed questions
content¶
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 |
Shortcut keys¶
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.
2. Customize through customizing a class¶
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.plugin
entrypoint
Check an example on how to configure BaseCommitizen
.
You can also automate the steps above through cookiecutter.
cookiecutter gh:commitizen-tools/commitizen_cz_template
See commitizen_cz_template for details.
Once you publish your rules, you can send us a PR to the Third-party section.
Custom commit rules¶
Create a Python module, for example cz_jira.py
.
Inherit from BaseCommitizen
, and you must define questions
and message
. The others are optional.
from commitizen.cz.base import BaseCommitizen
from commitizen.defaults import Questions
class JiraCz(BaseCommitizen):
# Questions = Iterable[MutableMapping[str, Any]]
# It expects a list with dictionaries.
def questions(self) -> Questions:
"""Questions regarding the commit message."""
questions = [
{"type": "input", "name": "title", "message": "Commit title"},
{"type": "input", "name": "issue", "message": "Jira Issue number:"},
]
return questions
def message(self, answers: dict) -> str:
"""Generate the message with the given answers."""
return "{0} (#{1})".format(answers["title"], answers["issue"])
def example(self) -> str:
"""Provide an example to help understand the style (OPTIONAL)
Used by `cz example`.
"""
return "Problem with user (#321)"
def schema(self) -> str:
"""Show the schema used (OPTIONAL)
Used by `cz schema`.
"""
return "<title> (<issue>)"
def info(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.
from setuptools import setup
setup(
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.
Custom bump rules¶
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.
from commitizen.cz.base import BaseCommitizen
class StrangeCommitizen(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 bump
Custom changelog generator¶
The 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 | list | None |
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 . Returning a falsy value ignore the commit. |
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 |
changelog_release_hook |
method: (release: dict, tag: git.GitTag) -> dict |
NO | Receives each generated changelog release and its associated tag. Useful to enrich a releases before they are rendered. Must return the update release |
from commitizen.cz.base import BaseCommitizen
import chat
import compliance
class StrangeCommitizen(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",
}
def changelog_message_builder_hook(
self, parsed_message: dict, commit: git.GitCommit
) -> dict | list | None:
rev = commit.rev
m = parsed_message["message"]
parsed_message[
"message"
] = f"{m} {rev} [{commit.author}]({commit.author_email})"
return parsed_message
def changelog_release_hook(self, release: dict, tag: git.GitTag) -> dict:
release["author"] = tag.author
return release
def changelog_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
"""
if partial_changelog:
chat.room("#committers").notify(partial_changelog)
if full_changelog:
compliance.send(full_changelog)
full_changelog.replace(" fix ", " **fix** ")
return full_changelog
Raise Customize Exception¶
If you want commitizen
to catch your exception and print the message, you'll have to inherit CzException
.
from commitizen.cz.exception import CzException
class NoSubjectProvidedException(CzException):
...
Migrating from legacy plugin format¶
Commitizen migrated to a new plugin format relying on importlib.metadata.EntryPoint
.
Migration should be straight-forward for legacy plugins:
- Remove the
discover_this
line from you plugin module - Expose the plugin class under as a
commitizen.plugin
entrypoint.
The name of the plugin is now determined by the name of the entrypoint.
Example¶
If you were having a CzPlugin
class in a cz_plugin.py
module like this:
from commitizen.cz.base import BaseCommitizen
class PluginCz(BaseCommitizen):
...
discover_this = PluginCz
Then remove the discover_this
line:
from commitizen.cz.base import BaseCommitizen
class PluginCz(BaseCommitizen):
...
and expose the class as entrypoint in you setuptools:
from setuptools import setup
setup(
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
.
Customizing the changelog template¶
Commitizen gives you the possibility to provide your own changelog template, by:
- providing one with your customization class
- providing one from the current working directory and setting it:
- as configuration
- as
--template
parameter to bothbump
andchangelog
commands
- either by providing a template with the same name as the default template
By default, the template used is the CHANGELOG.md.j2
file from the commitizen repository.
Providing a template with your customization class¶
There is 3 parameters available to change the template rendering from your custom BaseCommitizen
.
Parameter | Type | Default | Description |
---|---|---|---|
template |
str |
None |
Provide your own template name (default to CHANGELOG.md.j2 ) |
template_loader |
str |
None |
Override the default template loader (so you can provide template from you customization class) |
template_extras |
dict |
None |
Provide some extra template parameters |
Let's see an example.
from commitizen.cz.base import BaseCommitizen
from jinja2 import PackageLoader
class MyPlugin(BaseCommitizen):
template = "CHANGELOG.md.jinja"
template_loader = PackageLoader("my_plugin", "templates")
template_extras = {"key": "value"}
This snippet will:
- use
CHANGELOG.md.jinja
as template name - search for it in the
templates
directory formy_plugin
package - add the
key=value
variable in the template
Providing a template from the current working directory¶
Users can provides their own template from their current working directory (your project root) by:
- providing a template with the same name (
CHANGELOG.md.j2
unless overridden by your custom class) - setting your template path as
template
configuration - giving your template path as
--template
parameter tobump
andchangelog
commands
Note
The path is relative to the current working directory, aka. your project root most of the time.
Template variables¶
The default template use a single tree
variable which is a list of entries (a release) with the following format:
Name | Type | Description |
---|---|---|
version | str |
The release version |
date | datetime |
The release date |
changes | list[tuple[str, list[Change]]] |
The release sorted changes list in the form (type, changes) |
Each Change
has the following fields:
Name | Type | Description |
---|---|---|
scope | str | None |
An optional scope |
message | str |
The commit message body |
sha1 | str |
The commit sha1 |
author | str |
The commit author name |
author_email | str |
The commit author email |
Note
The field values depend on the customization class and/or the settings you provide
When using another template (either provided by a plugin or by yourself), you can also pass extra template variables by:
- defining them in your configuration with the
extras
settings - providing them on the commandline with the
--extra/-e
parameter tobump
andchangelog
commands