KPN'S COMMITIZEN
About
Plugin for python's commitizen, which uses KPN commit rules to bump versions, update files and generate changelogs.
KPN Rules summary
Schema
<PREFIX>(<SCOPE>): <SUBJECT> (#<ISSUE_ID>)
<LONG_DESCRIPTION>
| Prefix | SemVer relation | Description |
|---|---|---|
FIX |
PATCH |
Backwards compatible change that fixes something |
OPT |
PATCH |
Other changes like refactors, docs, which are backwards compatible |
NEW |
MINOR |
New functionality |
BREAK |
MAJOR |
Breaking changes |
Examples
NEW: Add login screen (#MY-123)
OPT(test): Add unittest for missing feature
Custom configuration
This rules support custom configuration. You can set any of the following options in your pyproject.toml file (non of them are mandatory):
[tool.commitizen]
# ...
kpn_strict_check = true
kpn_commit_url = "https://github.com/kpn/cz-kpn/commit/$COMMIT_REV"
kpn_app_name = "foobar"
kpn_strict_check: Enable strict mode duringcz checkandcz commit.kpn_commit_url: URL to the commit page on your version control system. Which will be used to generate the changelog.kpn_app_name: Use thescopeto filter commits when bumping and creating a changelog. Ideal for monorepos.
Installation
Install in your system
python -m pip install --user cz-kpn
Or add cz-kpn to your project:
# uv
uv add --dev cz-kpn
# poetry
poetry add cz-kpn --group dev
Quickstart
Initialize cz-kpn in your project
Answer the questions appearing in:
cz init
Bumping and changelog
Just run:
cz bump
Committing
cz commit
or the shortcut
cz c
With docker
cmd="cz -n cz_kpn commit"
docker run --rm -it -v $(pwd):/app kpnnl/cz-kpn:5.2.0 $cmd
Features
Client tool to assist in the creation of a commit
]
note: gif is outdated
This command is useful for newcomers, or when you don't remember the meaning of each change type. It will display a prompt which will guide the user in the commit creation.
cz commit
git cz commit
Automatic version bump
Automatic version bump with changelog generation.
cz bump --changelog
Note: The --changelog flag is not required if update_changelog_on_bump = true
Automatic Changelog Generation
If you don't want to generate a tag and bump the version, run:
cz changelog
This will create a changelog with unreleased commits, alternatively, you can run
cz changelog --incremental
to add only the missing changes. This is useful if you have manually modified your changelog.
Validate Commit Message
This command will tell you if there are any valid or invalid commit messages in the given range.
You can also add it to .pre-commit hooks or manually as a git hook.
More info in commitizen website.
cz check --rev-range ugnu348hg84hg84g..j8fj84g84h84hg83h2392
You can also check against the last version:
cz check --rev-range "$(cz version -p).."
Configuration
The recommendation is to run cz init which will help you create the
right configuration and file.
You can also add manually to your pyproject.toml or create a .cz.toml file with:
[tool.commitizen]
name = "cz_kpn"
version = "<YOUR_CURRENT_VERSION>"
version_files = [
"src/__version__.py"
]
bump_message = "BUMP: version ${current_version} → ${new_version}"
annotated_tag = true # recommended!
Help
cz --help
Contents:
$ cz --help
usage: cz [-h] [--config CONFIG] [--debug] [-n NAME] [-nr NO_RAISE]
{init,commit,c,ls,example,info,schema,bump,changelog,ch,check,version} ...
Commitizen is a powerful release management tool that helps teams maintain consistent and meaningful commit messages while automating version management.
For more information, please visit https://commitizen-tools.github.io/commitizen
options:
-h, --help show this help message and exit
--config CONFIG the path of configuration file
--debug use debug mode
-n NAME, --name NAME use the given commitizen (default: cz_conventional_commits)
-nr NO_RAISE, --no-raise NO_RAISE
comma separated error codes that won't raise error, e.g: cz -nr 1,2,3 bump. See codes at
https://commitizen-tools.github.io/commitizen/exit_codes/
commands:
{init,commit,c,ls,example,info,schema,bump,changelog,ch,check,version}
init init commitizen configuration
commit (c) create new commit
ls show available commitizens
example show commit example
info show information about the cz
schema show commit schema
bump bump semantic version based on the git log
changelog (ch) generate changelog (note that it will overwrite existing file)
check validates that a commit message matches the commitizen schema
version get the version of the installed commitizen or the current project (default: installed commitizen)
Testing
For details about supported Python versions and local testing instructions, see PYTHON_TESTING.md.
Contributing
Read Contributing guide
Using in a GitHub Action
name: Bump version and generate changelog
on:
push:
branches:
- main
jobs:
bump-version:
if: ${{ !startsWith(github.event.head_commit.message, 'BUMP:') }}
runs-on: ubuntu-latest
name: "Bump version and create changelog with commitizen"
steps:
- name: Check out
uses: actions/checkout@v7
with:
fetch-depth: 0
token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
- name: Create bump and changelog
uses: commitizen-tools/commitizen-action@master
id: cz
with:
github_token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
changelog_increment_filename: body.md
extra_requirements: "cz-kpn"
- name: Release
uses: softprops/action-gh-release@v1
with:
body_path: "body.md"
tag_name: ${{ steps.cz.outputs.version }} # Or use env.REVISION
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
The secrets.PERSONAL_ACCESS_TOKEN is required in order to trigger other actions observing the tag creation.
An alternative is to use workflow_call to trigger the workflow from the current workflow.
Read more in commitizen docs
Monorepos
You can now use cz-kpn in monorepos by leveraging the kpn_app_name option in the scope.
Let's say you have this setup:
.
├── app-orders
│ └── .cz.toml
└── app-analytics
└── .cz.toml
Each with their own config, like:
# app-orders/.cz.toml
[tool.commitizen]
name = "cz_kpn"
version = "0.0.1"
version_scheme = "semver2"
tag_format = "${version}-orders"
bump_message = "BUMP: version ${current_version}-orders → ${new_version}-orders"
ignored_tag_formats = ["${version}-*"] # Avoid noise from other tags
update_changelog_on_bump = true
major_version_zero = true
# The important stuff!!
annotated_tag = true # required!
kpn_app_name = "orders"
# app-analytics/.cz.toml
[tool.commitizen]
name = "cz_kpn"
version = "0.0.1"
version_scheme = "semver2"
tag_format = "${version}-analytics"
bump_message = "BUMP: version ${current_version}-analytics → ${new_version}-analytics"
ignored_tag_formats = ["${version}-*"] # Avoid noise from other tags
update_changelog_on_bump = true
major_version_zero = true
# The important stuff!!
annotated_tag = true # required!
kpn_app_name = "analytics"
Now we can run each of them individually, and if you have a commit log like this:
FIX(analytics): Use proper config
NEW(orders): Add tables
OPT: Update generic stuff
You can bump each of the parts individually, and they will pick up their relevant commits, and each will have their own changelog:
# This one will only see NEW(orders)
cz --config app-orders/.cz.toml bump --yes
# This one will only see FIX(analytics)
cz --config app-analytics/.cz.toml bump --yes
This is how the output would look
.
├── app-orders
│ ├── .cz.toml
│ └── CHANGELOG.md
└── app-analytics
├── .cz.toml
└── CHANGELOG.md
Metadata
Release files for cz-kpn 5.2.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| cz_kpn-5.2.0.tar.gz | 808.5 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| cz_kpn-5.2.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 818.0 kB
Release files / cz_kpn-5.2.0.tar.gz
| Download URL | cz_kpn-5.2.0.tar.gz |
|---|---|
| Size | 808.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
08fd421b5f914d4a10ccb816827bc0400a9970565e20d992e1c65a21e139dd77
|
|
BLAKE2b-256 checksum How to use checksums |
64f256c5c110109666cae875b23da93b34ce2cc7396ee067638ecc121f5d8529
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 22, 2026.
Transparency logRelease files / cz_kpn-5.2.0-py3-none-any.whl
| Download URL | cz_kpn-5.2.0-py3-none-any.whl |
|---|---|
| Size | 9.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
7d13bf09b203945cb0f0aea6e00d6a09de2689c83e94ed8871a83baccde6f6e0
|
|
BLAKE2b-256 checksum How to use checksums |
ebc22afa0bb30e860fe401bcd129c7bd2f61943e16d163a52617377628f93908
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 22, 2026.
Transparency log