Git release bot - PART 1

Published Jul 19, 2020

The content here is under the Attribution 4.0 International (CC BY 4.0) license

Releasing software to the final users is challenging regardless of the programming language of choice. For web apps it requires a web server, for compiled apps it requires a way for distribute the binary and for each one extra steps are needed, in the end the release is just the final step of a long process.

In the old days, applications where deployed via SFTP and required to move file by file in the server, later on git, was used to make the changes a bit easier, without the need to upload file by file then the devops and continuous integration/delivery came to support the agile practices.

Git bot comes to continue the continuous integration/deploy in the development process based on conventional commits and semantic version. Git bot is an attempt to make the boring task to change files (package.json or composer.json) versions for each released an automated process.

The problem with releases

To release a version of a software, usually there is a boring task of updating specific files with the version to be released. For example, a team may want to update the package.json file (version property) with the release they are tagging, for documentation purpose. Then, before a release the developer in charge of the release must remember to follow the rules of updating the file, and after that generate a git tag.

In the scenario described the major issue is to relay on the developer to always remember to update the file, which is fine, but what if the release requires to update two, or even three files? There is the human aspect of it as well, we are humans and we are error prone, which we can sometimes, forget to do things. In this case, the developer can also forget to update the files before the release, and then if it happens, the developer should follow a specific flow to change the file (or files) and release again.

Git bot concept

The git bot project is based in two major conventions:

Conventional commits (missing reference)
Semantic version [1]

In practice git bot integrates with a git repository and watches through webhook for pushes into a specific branch (or branches) which can be configured through the web interface. Once a push is made git bot receives the commit (or commits) content, and then analyze the commit title for one specific match:

chore: tagged version x.x.x

As a first approach the version pattern is constrained to use numeric versions, only, (this is a limitation added just for speed up the prof of concept), for example, the following version is valid:

chore: tagged version 10.2.0

Therefore, the following version is not:

chore: tagged version 10.2.0-rc

Once Git bot detects the match, it will automatically push the changes to the files with the specific version. The following flow chart describes the flow that is executed starting from the git repository (Gitlab).

Currently Git bot implementation [2] supports Gitlab only, but it’s core was designed to support other git providers, such as github or bitbucket.

References

[1]T. Preston-Werner, “Semantic Versioning 2.0.0,” 2020 [Online]. Available at: https://semver.org. [Accessed: 17-Aug-2020]
[2]M. Marabesi, “Git bot release,” 2020 [Online]. Available at: https://github.com/marabesi/git-bot-release. [Accessed: 17-Aug-2020]