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.
cz commit command with default Espressif commit types, aligned with the Espressif pre-commit linter.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 czespressif
Then 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 example
[!TIP] You can also add it to your project
devdependencies (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 changelog
Is better to first run:
cz bump --dry-run
This 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 example
This 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 = true
The 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'."
fi
[!TIP] 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-changelog
Next, run the following command to fetch the latest version (rev:):
pre-commit autoupdate --repo https://github.com/espressif/cz-plugin-espressif
If 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.
FAQs
Commitizen plugin with Espressif code style
We found that czespressif demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.
Security News
The Ultralytics' PyPI Package was compromised four times in one weekend through GitHub Actions cache poisoning and failure to rotate previously compromised API tokens.