This repository contains three tools enabling continuous deployment using Conventional Commits - two GitHub actions and a pre-commit
hook:
git-mkver
to
predict what the version of the package should be as of the HEAD
commit and checks if this matches the version as
currently stated in a setup.py
, setup.cfg
, pyproject.toml
, or package.json
file.commit-msg
-type pre-commit
hook that checks if the current commit message adheres to
the Conventional Commit standard.The GitHub actions can be combined with an automatic release-on-pull-request-merge workflow to facilitate continuous deployment of correctly semantically-versioned code changes to your users (as long as all contributers categorise their commits correctly as breaking changes, new features, and bug-fixes/small-changes). Examples of workflows that do this are linked below. You can find an example release workflow here.
A commit-msg
-type pre-commit
hook that checks whether each commit message adheres to the
Conventional Commits standard, as well as the additional customisable
rules that:
You can provide values for each of these rules, including another set of commit codes to override or augment the defaults.
You can change these for a repository (see 'Usage' below) for your requirements. Across octue, we use:
FEA
: A new featureENH
: An improvement or optimisation to an existing featureFIX
: A bug fixOPS
: An operational/devops/git change e.g. to continuous integration scripts or GitHub templatesDEP
: A change in dependenciesREF
: A refactor of existing codeTST
: A change to tests or the testing frameworkMRG
: A merge commitREV
: A reversion e.g. a git revert
commitCHO
: A chore e.g. updating a menial configuration file or .gitignore fileWIP
: A work-in-progress commit (usually to be avoided, but makes sense for e.g. trying changes in git-based CI)DOC
: A change to documentation, docstrings, or documentation generationSTY
: A change to code style specifications or to code to conform to new styleUse this hook in your repository by adding it to your .pre-commit-config.yaml
file as:
- repo: https://github.com/octue/conventional-commits
rev: 0.0.2 # (or another version)
hooks:
- id: check-commit-message-is-conventional
stages: [commit-msg]
args:
- --additional-commit-codes=ABC,DEF,GHI
- --maximum-header-length=72
- --valid-header-ending-pattern=[A-Za-z\d]
- --require-body=0
- --maximum-body-line-length=72
Then, install pre-commit
if you haven't already:
pip install pre-commit
Finally, install the hook:
pre-commit install && pre-commit install -t commit-msg
Note that while this hook complies with nearly all of the Conventional Commits specification, it is diverges slightly in the following ways:
FEA
is used instead of feat
git log --oneline
view for ease of viewing and mental (human)
parsing. We require that they are always provided in uppercase in commit headers, again to increase ease of
viewing. Despite this, you can add your own codes to this default set that are in whatever form you like (e.g.
any number of letters in lowercase).Only using 3-letter uppercase commit codes/types results in a uniform, easily readable git log. There is a clear distinction between the code and the title of the commit, and the eye doesn't have to jump left and right on each new line to find the start of the title. Here is an example from our own git log:
>>> git log --oneline -10
82f5953 ENH: Validate breaking change indicators in commit messages (HEAD -> main)
810944a ENH: Improve range of commit codes available
311f4f5 REF: Move comment removal into method (origin/main, origin/HEAD)
ba2aca3 IMP: Explain commit codes in error message
f0142c2 DOC: Update README
214af4f TST: Test optional CLI args
417efcc IMP: Add DOC and LOG commit codes
d528edd OPS: Use version of hook specified in this repo locally
5b5727c IMP: Allow options to be passed to hook
86e07c5 CLN: Apply pre-commit checks to all files