This is a plugin for Commitizen that makes it easy to create and maintain a well-organized and good-looking CHANGELOG.md. It also takes care of version bumping and helps you write commit messages that follow Espressif standards.
All of this with minimal config and setup, so your pyproject.toml file stays clean and simple.
- Commitizen plugin czEspressif
- Can be almost zero-config but offers many customization options if your project needs it.
- Predefined CHANGELOG template with default categories Breaking changes / New features / Bug fixes / Documentation / Code refactoring / Removals.
- The CHANGELOG automatically displays commits and the authors of those commits.
- The default order in the changelog categories lists commits with a scope first, followed by the rest, both groups sorted alphabetically.
- Predefined Release Notes template that can be used in an automated release workflow.
cz commitcommand with default Espressif commit types, aligned with the Espressif pre-commit linter.- You can use pre-commit hook that triggers a local changelog update (Unreleased section) when version files change.
This plugin requires Python 3.9 or higher. It should run on pretty much any anything (Linux, Mac, Windows, amd64, aarch64).
If you encounter issues with a specific architecture or OS, please report it here, and we will try to address it as soon as possible.
Install with pip or your favorite package manager:
pip install czespressifThen add this snippet to `pyproject.toml:
[tool.commitizen]
name = "czespressif"
bump_message = 'change(bump): release $current_version → $new_version [skip-ci]'And verify that installation and setup was successful by showing the example.
cz exampleTip
You can also add it to your project dev dependencies (suggested) and run the sync command (pipenv sync, pip-sync, poetry install, ...).
commitizen itself is in the plugin's dependencies, so pip will take care of everything.
Warning
Don't try to install it system-wide with pipx; it likely won't work as expected.
(This option will be explored in the future, and once a solution is found, we will update this recommendation.)
Tip
You can check the implementation of this command in the GitHub workflow .github/workflows/create-release.yml if you're interested.
In this project's tests/snapshots/test_changelog/ directory, we store snapshots used for automated testing. These snapshots also serve as examples of the plugin's output.
You can explore them and compare the plugin output (test_changelog_czespressif_*.md) with the default Commitizen output (test_changelog_cz_default_*.md), which is generated when our plugin is not used.
If a changelog already exists in your project, make sure you have staged or committed its latest version.
This command turns your old changelog into a nicely organized template based on the Keep a Changelog standard.
cz changelogIs better to first run:
cz bump --dry-runThis only shows the future version and the part of the changelog that will be updated. When all ok, do the same without --dry-run flag.
In automated scenarios, such as GitHub Actions workflows, you may want to create project releases automatically. This can be easily achieved by parsing the changelog to extract the "Release notes" relevant to the current release.
In this repository, there is a GitHub workflow (.github/workflows/create-release.yml) that follows this strategy. To trigger a release, the repository admin simply needs to push a release tag to the origin (GitHub).
This triggers the workflow, which builds all Python binaries for all combinations of Python versions, operating systems, and architectures. It then parses the changelog to extract the release notes (only the section related to the current release, without any headers, footers, etc.), creates a GitHub release, and uploads the binaries both to the GitHub release and the PyPI registry.
The following command generates the changelog for the release version v4.8.0, using the internal template for release notes and writing the partial changelog to a file:
cz changelog v4.8.0 --template="RELEASE_NOTES.md.j2" --file-name="Release_notes.md"
Release notes custom footer: You can append a custom footer to the end of the release notes snippet. For example, if you want to include a link to something important for your project, or maybe some GitHub badges, and so on, you can do that.
You can check example without a footer (default) and example with a custom footer.
Important
Note that the custom template for release notes is part of the czespressif plugin, not the target (your project) repository. Any custom settings you define for the changelog locally in the project configuration will also apply to the release notes. For example, if you change the order of sections in the changelog, the release notes will reflect that change as well.
This approach ensures consistent visual styling and allows repository admins to configure everything in one place.
Tip
You can check the implementation of this command in the GitHub workflow .github/workflows/create-release.yml if you're interested.
In case anyone actually prefers this way of creating commit messages, the command in this plugin is aligned with the Espressif commit linter and DangerJS linters.:
cz commit? Select the type of change you are committing (Use arrow keys)
» feat ✨ A new feature
fix 🐛 A bug fix
change 🏗️ A change made to the codebase.
docs 📖 Documentation only change
test 🚦 Adding missing or correcting existing tests
ci ⚙️ Changes to CI configuration files and scripts
refactor 🔧 A changeset neither fixing a bug nor adding a feature
revert 🔙 Revert one or more commits
remove 🗑️ Removing code or files
If you are unsure about the commit message standard, run:
cz exampleThis will bring up a complete example of good commit messages and commit schema in the terminal.
Config is accepted in pyproject.toml (priority, following example), .cz.toml, .cz.json, cz.json, .cz.yaml, cz.yaml, and cz.toml.
Tip
Try to be minimalistic with custom configs. The best approach is to keep the defaults, so all Espressif projects maintain the same look and feel. Also, you will save yourself troubles with non-standard setups.
[tool.commitizen]
name = "czespressif"
bump_message = 'change(bump): release $current_version → $new_version [skip-ci]'[tool.commitizen]
name = "czespressif"
bump_message = 'change(bump): release $current_version → $new_version [skip-ci]'
# see commitizen docs, following are standard configs
annotated_tag = true
changelog_merge_prerelease = true
tag_format = "v$version"
update_changelog_on_bump = true
version = "1.2.3"
version_files = ["<src>/__init__.py:__version__"]
version_provider = "commitizen"
[tool.commitizen]
...
# - Section emojis in the changelog, emojis in CLI command `cz commit` -
# Default: true; false = do not display emojis
# Note: Emojis are never added in the commit messages.
use_emoji = false
# - Custom text of changelog title -
# Note: "" (empty string) disables title
changelog_title = "Our changelog"
# - Custom text of changelog header -
# Note: "" (empty string) disables header
changelog_header = "This is our changelog.\nAll cool things we do are here.\n\nPlease read it."
# - Custom text of changelog footer -
# Note: "" (empty string) disables footer
changelog_footer = "This is the end of our changelog.\n\nMore cool things are coming."
# - Horizontal lines between release sections in the changelog -
# Default: true; false = removes lines
changelog_section_line = false # default (true); false = removes horizontal lines between releases
# - Section "Unreleased" in the changelog -
# Default: true; false = removes section Unreleased, keeps only releases
changelog_unreleased = false
# - Authors of the changes (commits) in the changelog -
# Default: true; false = do not display authors
changelog_show_authors = false
# - Commit numbers (short SHA) in the changelog -
# Default: true; false = do not display commit numbers
changelog_show_commits = false
# - Change orders in which sections displays in the changelog -
# Default: this example is default
change_type_order = [ # with enabled emojis
'🚨 Breaking changes',
'✨ New features',
'🐛 Bug fixes',
'📖 Documentation',
'🔧 Code refactoring',
'🗑️ Removals',
'🏗️ Changes', # in default not in the changelog
'⚙️ CI and project settings', # in default not in the changelog
'🚦 Testing', # in default not in the changelog
'🔙 Reverted', # in default not in the changelog
]
change_type_order = [ # same thing, with disabled emojis
'Breaking changes',
'New features',
'Bug fixes',
'Documentation',
'Code refactoring',
'Removals',
'Changes', # in default not in the changelog
'CI and project settings', # in default not in the changelog
'Testing', # in default not in the changelog
'Reverted', # in default not in the changelog
]
# - Redefine which types are shown in the changelog -
# Note: You need to list here ALL types that you want to have in the changelog - included default ones
# Note: The order in this list doesn't matter — if you want to change the sections' order too, use with "change_type_order."
types_in_changelog = ["feat", "fix", "refactor", "style", "ci"]
# - Custom text that you can append to release notes output -
# Default: Null (in default there is no custom footer )
release_notes_footer = """Thanks to <FILL OUT CONTRIBUTORS>, and others for contributing to this release!"""
# - Add extra commit types for 'cz commit' and to the changelog (sections) -
# Note: If you are working with custom commit types, ensure your commit linter and PR/MR linter is set same way
[[tool.commitizen.extra_types]]
type = "style"
heading = "Code Style"
emoji = "🎨"
description = "Changes that do not affect the meaning of the code (white-space, formatting, etc.)"
bump = "PATCH"
changelog = trueThe plugin czespressif has commitizen as its dependency, so users only need to install czespressif, and that will automatically install the proper version of commitizen. This plugin requires at least version 3.29 of commitizen to work properly. Older versions either cause errors like this:
The committer has not been found in the system.
Try running 'pip install czespressif'
... or czespressif plugin partially works but behaves in weird and unexpected ways.
If you encounter this error, it probably means that you have a conflicting version of commitizen installed on your system, and this old version is prioritized in your system path.
You can copy and paste this snippet into your terminal to check if this is the case:
clear;if command -v cz &> /dev/null; then
cz_version=$(cz version | awk '{print $NF}')
if [ "$(printf '%s\n' "3.29" "$cz_version" | sort -V | head -n1)" = "3.29" ]; then
echo "Commitizen version $cz_version is OK."
else
echo "Commitizen version $cz_version is too old. Found at $(which cz)."
echo "Please uninstall it with 'pip uninstall commitizen' or 'pipx uninstall commitizen'."
fi
else
echo "No Commitizen found, but you are not in a virtual environment."
echo "Consider creating/activating a virtual environment first and installing by 'pip install czespressif'."
fiTip
For each Python project, use a virtual environment. If you install everything with pip to the system Python, you risk running into unsolvable dependency issues and possibly breaking some system tools.
If your project isn’t a Python project and you don’t care about python virtual envs, at least ensure you don’t have multiple outdated versions of some Python packages, such as commitizen in this case.
To automatically keep your changelog's "Unreleased" section up to date, add the following to your .pre-commit-config.yaml file:
- repo: https://github.com/espressif/cz-plugin-espressif
rev: ''
hooks:
- id: update-changelogNext, run the following command to fetch the latest version (rev:):
pre-commit autoupdate --repo https://github.com/espressif/cz-plugin-espressifIf you have already set default_install_hook_types, then include pre-push in the list. Otherwise, add the following to your .pre-commit-config.yaml file:
default_install_hook_types: [pre-commit, pre-push]After installing the hook, it runs automatically before you pushing commits to the repository. It updates the changelog with the latest commits. If the push failed because of the hook, don't forget to add the updated changelog to the commit and push again.
We welcome contributions from the community! Please read the Contributing Guide to learn how to get involved.
This PROJECT is licensed under the Apache 2.0 License.
This was inspired by the project Emotional, created by Axel H. / @noirbizarre.
-
If you are looking for similar and customizable plugin for projects outside Espressif organization, you should definitely try Emotional.
-
If you are learning Python and want to write clean and well-organized, pro-level code, you should definitely check out Emotional.