pygitver

Features:

• Conventional Commit linter
• Generate CHANGELOG and group of CHANGELOGs
• Bump version based on CHANGELOG

Install

Use as python CLI (python is required)

pip install pygitver

Use as a docker container (docker engine is required)

docker pull panpuchkov/pygitver

Users (Developers) Section

Install Conventional Commit Git Hook Checker

Run in the git root folder of the target repository on localhost.

docker run --rm -v $(pwd):/app -w /app --user "$(id -u):$(id -g)" --entrypoint '' panpuchkov/pygitver /pygitver/scripts/install.sh

• It doesn't matter what the current branch is.
• You should install it in every repository that needs conventional commit messages.

Update pygitver

Run in a terminal in any folder:

docker pull panpuchkov/pygitver

Git Conventional Commit Linter

You don't need to use it directly; it will be used automatically on each git commit.

Example of a commit message that is NOT VALID for Conventional Commits:

$ git commit -am "test"
ERROR: Commit does not fit Conventional Commits requirements

Example of a commit message that is VALID for Conventional Commits:

$ git commit -am "feat: test"
[feature/test2 af1a5c4] feat: test
 1 file changed, 1 deletion(-)

Note: repeat this procedure for each repository

DevOps and Developers Section

Examples

You may use it as a CLI tool (Python PIP package) or a Docker container.

Usage as PIP Package (python is required)

Check commit message

$ pygitver --check-commit-message "feat: conventional commit example"
$ echo $?
0
$ pygitver --check-commit-message "non-conventional commit example"
ERROR: Commit does not fit Conventional Commits requirements
More about Conventional Commits: https://www.conventionalcommits.org/en/v1.0.0/
$ echo $?
1

Get current/next version

$ git tag -l
v0.0.1
v0.0.2
$ pygitver --curr-ver
v0.0.2
$ pygitver --next-ver
v0.0.3

Generate changelog

$ pygitver changelog
##########
Change Log
##########

Version v0.0.3
=============

Features
--------

* Allow to trigger job manually

Bug Fixes
---------

* Path for the default changelog template

* Readme.md usage

Improved Documentation
----------------------

* Add examples to the readme.md

$ pygitver changelog --format json | jq .
{
  "version": "v0.0.3",
  "bump_rules": {
    "major": false,
    "minor": false,
    "patch": true
  },
  "changelog": {
    "features": [
      "allow to trigger job manually"
    ],
    "bugfixes": [
      "path for the default changelog template",
      "README.md usage"
    ],
    "deprecations": [],
    "others": [],
    "docs": [
      "Add examples to the README.md"
    ],
    "non_conventional_commit": []
  }
}

Usage as Docker container (docker engine is required)

$ git tag -l
v0.0.1
v0.0.2
$ docker run --rm -v $(pwd):/app -w /app --user "$(id -u):$(id -g)" panpuchkov/pygitver --curr-ver
v0.0.2
$ docker run --rm -v $(pwd):/app -w /app --user "$(id -u):$(id -g)" panpuchkov/pygitver --next-ver
v0.0.3
$ docker run --rm -v $(pwd):/app -w /app --user "$(id -u):$(id -g)" panpuchkov/pygitver changelog
##########
Change Log
##########

Version v0.0.3
=============

Features
--------

* Allow to trigger job manually

Bug Fixes
---------

* Path for the default changelog template

* Readme.md usage

Improved Documentation
----------------------

* Add examples to the readme.md

$ docker run --rm -v $(pwd):/app -w /app --user "$(id -u):$(id -g)" panpuchkov/pygitver changelog --format json | jq .
{
  "version": "v0.0.3",
  "bump_rules": {
    "major": false,
    "minor": false,
    "patch": true
  },
  "changelog": {
    "features": [
      "allow to trigger job manually"
    ],
    "bugfixes": [
      "path for the default changelog template",
      "README.md usage"
    ],
    "deprecations": [],
    "others": [],
    "docs": [
      "Add examples to the README.md"
    ],
    "non_conventional_commit": []
  }
}
$ docker run --rm -v $(pwd):/app -w /app --user "$(id -u):$(id -g)" panpuchkov/pygitver --help
usage: pygitver.py [-h] [-v] [-cv] [-nv] [-t] [-ccm CHECK_COMMIT_MESSAGE]
                   {changelog,changelogs} ...

pygitver tool, ver: 0.2.5

options:
  -h, --help            show this help message and exit
  -v, --version         show tool version
  -cv, --curr-ver       get current version (last git tag)
  -nv, --next-ver       get next version (bump last git tag)
  -t, --tags            git tags
  -ccm CHECK_COMMIT_MESSAGE, --check-commit-message CHECK_COMMIT_MESSAGE
                        check if the git commit message is valid for
                        Conventional Commits

Get changelog:
  {changelog,changelogs}
                        Get changelog in TEXT or JSON format

Custom CHANGELOG Templates

• Take as an example: ./src/pygitver/templates/changelog.tmpl
• Place somewhere in your project custom template
• Send environment variable PYGITVER_TEMPLATE_CHANGELOG to docker on run with full template path in Docker (usually /app/...)

Custom Git Tag Version Prefix

If a Git repository has more than one application/service, you may need to have different versions for each of them. Example

$ git tag -l
app_a_1.2.3
...
app_b_2.5.2
...

If you want to get the current and next versions for app_a, you can use the environment variable PYGITVER_VERSION_PREFIX. Example:

$ PYGITVER_VERSION_PREFIX=app_a_ python -m pygitver.pygitver --curr-ver
app_a_1.2.3
$ PYGITVER_VERSION_PREFIX=app_a_ python -m pygitver.pygitver --next-ver
app_a_1.3.0
$ PYGITVER_VERSION_PREFIX=app_b_ python -m pygitver.pygitver --curr-ver
app_b_2.5.2
$ PYGITVER_VERSION_PREFIX=app_b_ python -m pygitver.pygitver --next-ver
app_b_2.6.0

Conventional Commits Rules

The tool supports simplified Conventional Commits, which are described in this section.

The commit message should be structured as follows:

<type>[optional scope]: <description>

The commit contains the following structural elements to communicate intent to the consumers of your library:

• fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
• feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
• BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
• Other allowed prefixes: build:, chore:, ci:, docs:, style:, refactor:, perf:, test:. These correlate with PATCH in Semantic Versioning.

Conventional Commits Examples:

Commit without scope without breaking change.

fix: crash on wrong input data

Commit message with ! to draw attention to breaking change.

feat!: send an email to the customer when a product is shipped

Commit message with scope and ! to draw attention to breaking change.

feat(api)!: send an email to the customer when a product is shipped

Commit message with scope.

feat(lang): add Polish language

Development

Build Docker

docker build -t pygitver .

Install to Localhost

pip install -r requirements-dev.txt

Test on Localhost

Run all checks

tox

A single file of the test run

tox -e coverage -- ./tests/test_git.py -vv

or

coverage run -m pytest -- ./tests/test_git.py 

Build pip package

Linux

python -m build

For Debian based OS:

DEB_PYTHON_INSTALL_LAYOUT=deb_system python3 -m build