Generate Changelog
Use your commit log to make a beautiful changelog file.
generate-changelog does what it says: it generates a full changelog, or updates an existing one. Git tags and commits are the inputs by which generate-changelog performs its task.
The primary goal of this tool was to provide the benefits of conventional commits without requiring a strict syntax. generate-changelog accomplishes this using configurable regular expressions or commit metadata matching. The thought is natural language is easier for developers to remember and requires less tooling to enforce.
Features
Commit and tag processing
- Filter out commits and tags based on regular expression matching.
- Classify commit messages into sections such as "New", "Fixes", and "Changes" using configurable regular expressions, metadata, or custom criteria.
- Rewrite commit summary or commit body using pipelines of actions.
- Extract parts of the commit summary or body into metadata available for templates and filters.
- Built-in issue parsers for Jira, GitHub, Azure DevOps Board.
- Built-in conventional commit parser
Changelog rendering
- Templated using Jinja templates.
- Each template has a large amount of metadata that allows linking to a commit, a version diff, and issue trackers.
- Easily customize just the template you want.
- Supports full or incremental changelog generation.
Release hints
- Can use user-defined rules to suggest a release type for use in another part of your CI pipeline.
Git support
- Supports your merge or rebase workflows and complicated git histories.
- Supports of multi-authors for one commit through configurable trailers key values.
- Built-in parser for turning trailers key values into metadata.
Requirements
Python 3.9 or higher.
Installation
$ pip install generate-changelog
Usage
Create a default configuration file.
$ generate-changelog --generate-config
This creates a file named .changelog-config.yaml. You can make changes to the default configuration.
Generate your changelog via:
$ generate-changelog
GitHub Action
Inputs
config_filePath to the config file if it is not one of the defaults.starting_tagStarting tag to generate a changelog from. Default is to start from the last tag in the current change log.skip_output_pipelineDo not generate or update the CHANGELOG, but still return the release hint.branch_overrideOverride the current branch for release hint decisions.
Outputs
release_hintThe suggested release type for the current orbranch_overridebranch.
Generated files
The changelog file is written based on the configuration and value of the branch_override input.
This file is not added to your Git repo.
You must add and commit it if you want to keep it.
Example usage
on: [push]
jobs:
sample_job:
runs-on: ubuntu-latest
name: Just an example
steps:
- name: Generate changelog and release hint
id: changelog
uses: callowayproject/generate-changelog@v0
with:
config_file: .changelog-config.yaml
- name: Use the release hint
run: echo "The release hint was ${{ steps.changelog.outputs.release_hint }}"
Release files for generate-changelog 0.17.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 | |
|---|---|---|---|
| generate_changelog-0.17.0.tar.gz | 267.3 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| generate_changelog-0.17.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 308.4 kB
Release files / generate_changelog-0.17.0.tar.gz
| Download URL | generate_changelog-0.17.0.tar.gz |
|---|---|
| Size | 267.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
238dac453721a51cfac0c4b05ff686661660c2e91cdcb5620eb813bbd988e2bd
|
|
BLAKE2b-256 checksum How to use checksums |
cb26c5fc3134dcfb9e4b7b9af2dd02d64836ccc7c4c12989b2b57cc84860fc79
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
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 Mar 26, 2026.
Transparency logRelease files / generate_changelog-0.17.0-py3-none-any.whl
| Download URL | generate_changelog-0.17.0-py3-none-any.whl |
|---|---|
| Size | 41.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
9e94d30ffdba5a3da615ea5f61028a840e4236a2914fd8f327ef1a934d6139af
|
|
BLAKE2b-256 checksum How to use checksums |
fd4eb8c823cb25f7ca6eb34a9f971fb0bc449f4ffbb31064a6dede2089b2c2ef
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
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 Mar 26, 2026.
Transparency log