Description
What is Changelog CI?
Changelog CI is a GitHub Action that generates changelog, prepends it to CHANGELOG.md file and commits it to a release pull request
How Does It Works:
It uses a python script with GitHub API to get the last release. Then it checks all the pull request merged after the last release and writes it to CHANGELOG.md or user provided file. The pull request title must start with release *anything else for example: Release 0.1.1 releasing a new version The Changelog CI will see the pull request and submit a commit to the pull request with the changes written in the CHANGELOG.md file.
Changelog CI alternatives and similar packages
Based on the "RESTful API" category.
Alternatively, view Changelog CI alternatives based on common mentions on social networks and blogs.
-
doccano
Open source annotation tool for machine learning practitioners. -
falcon
The no-magic web data plane API and microservices framework for Python developers, with a focus on reliability, correctness, and performance at scale. -
hug
Embrace the APIs of the future. Hug aims to make developing APIs as simple as possible, but no simpler. -
django-tastypie
Creating delicious APIs for Django apps since 2010. -
connexion
Swagger/OpenAPI First framework for Python on top of Flask with automatic endpoint validation & OAuth2 support -
Django REST Swagger
Swagger Documentation Generator for Django REST Framework: deprecated -
Flask RestPlus
Fully featured framework for fast, easy and documented API development with Flask -
Dependency Injector
Dependency injection framework for Python -
pycord
Pycord, a maintained fork of discord.py, is a python wrapper for the Discord API -
django-sql-explorer
Easily share data across your company via SQL queries. From Grove Collab. -
sandman2
Automatically generate a RESTful API service for your legacy database. No code required! -
django-admin-interface
:superhero: :zap: django's default admin interface with superpowers - customizable themes, popup windows replaced by modals and many other features. -
flask-restless
NO LONGER MAINTAINED - A Flask extension for creating simple ReSTful JSON APIs from SQLAlchemy models. -
Blueprint/Boilerplate For Python Projects
Blueprint/Boilerplate For Python Projects -
apispec
A pluggable API specification generator. Currently supports the OpenAPI Specification (f.k.a. the Swagger specification).. -
nextcord
A Python wrapper for the Discord API forked from discord.py -
Flask Google Maps
Easy way to add GoogleMaps to Flask applications. maintainer: @getcake -
PEP 8 Speaks
A GitHub :octocat: app to automatically review Python code style over Pull Requests -
django-treenode
:deciduous_tree: probably the best abstract model/admin for your tree based stuff. -
pyswagger
An OpenAPI (fka Swagger) client & converter in python, which is type-safe, dynamic, spec-compliant. -
django-maintenance-mode
:construction: :hammer_and_wrench: shows a 503 error page when maintenance-mode is on. -
flask_for_startups
Flask boilerplate using a services oriented structure -
ripozo
A tool for quickly creating REST/HATEOAS/Hypermedia APIs in python -
django-newsfeed
A news curator and newsletter subscription package for Django -
appkernel
API development made easy: a smart Python 3 API framework -
Flask-Diamond
:gem: Flask-Diamond is a batteries-included Flask framework. -
Flask Paper Kit
Flask Boilerplate - Paper Kit Design | AppSeed -
discord-interactions-python
Useful tools for building interactions in Python -
#<Sawyer::Resource:0x00007f160f191eb0>
Python package for webscraping in Natural language -
django-modern-rpc
Simple XML-RPC and JSON-RPC server for modern Django -
django-template
A battle-tested Django 2.1 project template with configurations for AWS, Heroku, App Engine, and Docker.
Updating dependencies is time-consuming.
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of Changelog CI or a related project?
README
What is Changelog CI?
Changelog CI is a GitHub Action that generates changelog,
Then the changelog is prepended to CHANGELOG.md
file and committed
and/or commented to the release Pull request.
How Does It Work:
Changelog CI uses python
and GitHub API
to generate changelog for a repository.
First, it tries to get the latest release
from the repository (If available).
Then, it checks all the pull requests merged after the last release using the GitHub API.
After that, it parses the data and generates the changelog
. Finally,
It writes the generated changelog at the beginning of the CHANGELOG.md
(or user-provided filename) file.
In addition to that, if a user provides a config (JSON file), Changelog CI parses the user-provided config file
and renders the changelog according to users config.
Then the changes are committed and/or commented to the release Pull request.
Usage:
To use this Action The pull request title must match with the default regex
or the user-provided regex
from the config file.
Default Title Regex: ^(?i:release)
(title must start with the word "release" (case insensitive))
Default Version Number Regex: This follows SemVer
(Semantic Versioning) pattern.
e.g. 1.0.0
, 1.0
, v1.0.1
etc.
For more details on Semantic Versioning pattern go to this link: https://regex101.com/r/Ly7O1x/3/
Note: you can provide your own regex
through the config
file
To Enable Commenting, Disable Committing, Group changelog items and many more options Look at the config file docs.
To integrate Changelog CI
with your repositories Actions,
Put this step inside your .github/workflows/workflow.yml
file:
- name: Run Changelog CI
uses: saadmk11/[email protected]
with:
# Optional, you can provide any name for your changelog file,
# defaults to ``CHANGELOG.md`` if not provided.
changelog_filename: MY_CHANGELOG.md
# Optional, only required when you want more customization
# e.g: group your changelog by labels with custom titles,
# different version prefix, pull request title and version number regex etc.
config_file: changelog-ci-config.json
# Optional, This will be used to configure git
# defaults to ``github-actions[bot]`` if not provided.
committer_username: 'test'
committer_email: '[email protected]'
env:
# optional, only required for ``private`` repositories
# and required if the changelog comment
# option is turned on through the config file
GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
Changelog CI Badge:

Output:
Config File Usage (Optional):
Changelog CI config file is a JSON
file that you can provide to you workflow like this:
with:
config_file: changelog-ci-config.json
The config file will give you more flexibility and customization options.
Configuration Options:
- header_prefix: The prefix before the version number. e.g.
version:
inVersion: 1.0.2
- commit_changelog: Value can be
true
orfalse
. if not provided defaults totrue
. If it is set totrue
then Changelog CI will commit to the release pull request. - comment_changelog: Value can be
true
orfalse
. if not provided defaults tofalse
. If it is set totrue
then Changelog CI will comment on the release pull request. This requiresGITHUB_TOKEN
to be added to the workflow. - pull_request_title_regex: If the pull request title matches with this
regex
Changelog CI will generate changelog for it. Otherwise, it will skip the changelog generation. Ifpull_request_title_regex
is not provided defaults to^(?i:release)
(title must start with the word "release" (case insensitive)). - version_regex: This
regex
tries to find the version number from the pull request title. in case of no match, changelog generation will be skipped. ifversion_regex
is not provided defaults toSemVer
pattern. - group_config: By adding this you can group changelog items by your repository labels with custom titles.
{ // Custom title for groups "title": "Bug Fixes", // pull request labels that will match this group "labels": ["bug", "bugfix"] }
See this example output with group_config
See this example output without group_config
Example Config File:
{
"header_prefix": "Version:",
"commit_changelog": true,
"comment_changelog": true,
"pull_request_title_regex": "^Release",
"version_regex": "v?([0-9]{1,2})+[.]+([0-9]{1,2})+[.]+([0-9]{1,2})\\s\\(\\d{1,2}-\\d{1,2}-\\d{4}\\)",
"group_config": [
{
"title": "Bug Fixes",
"labels": ["bug", "bugfix"]
},
{
"title": "Code Improvements",
"labels": ["improvements", "enhancement"]
},
{
"title": "New Features",
"labels": ["feature"]
},
{
"title": "Documentation Updates",
"labels": ["docs", "documentation", "doc"]
}
]
}
In this Example version_regex
matches any version number including date. e.g: v1.1.0 (01-23-2018)
If you don't provide any regex
Changelog CI will use default
SemVer
pattern. e.g. 1.0.1
, v1.0.2
.
Here pull_request_title_regex
will match any pull request that starts with Release
you can match Any Pull Request Title by adding this pull_request_title_regex": ".*"
,
Click here to see the example output using this config
Example Workflow
name: Changelog CI
# Controls when the action will run. Triggers the workflow on a pull request
on:
pull_request:
types: [opened, reopened]
jobs:
build:
runs-on: ubuntu-latest
steps:
# Checks-out your repository
- uses: actions/checkout@v2
- name: Run Changelog CI
uses: saadmk11/[email protected]
with:
changelog_filename: CHANGELOG.md
config_file: changelog-ci-config.json
# Add this if you are using it on a private repository
# Or if you have turned on commenting through the config file.
env:
GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
Changelog CI in Action (Comment & Commit)
Example Changelog Output using config file:
Version: v2.1.0 (02-25-2020)
Bug Fixes
New Features
- #68: Update README.md
Documentation Updates
- #66: Docs update
Version: v1.1.0 (01-01-2020)
Bug Fixes
Documentation Updates
- #66: Docs update
Example Changelog Output without using config file:
Version: 0.0.2
Version: 0.0.1
- #43: It feels like testing never ends
- #35: Testing again and again
- #44: This is again another test, getting tired
- #37: This is again another test
License
The code in this project is released under the [MIT License](LICENSE).
*Note that all licence references and agreements mentioned in the Changelog CI README section above
are relevant to that project's source code only.