Semantic Versioning in Gitlab

Automated Semantic Versioning and Changelog Management in Gitlab

Taking care of versioning and branches becomes a tedious task as the project grows and new things start adding to it. Hence, it is always suggested to automate such tasks and get rid of the headache.

If your project is hosted on Gitlab and you want a simple automated solution to manage version releases and branches, this is the right place. It is pretty simple to achieve this through CI/CD.

In this post, I will help you achieve this without using any third party plug-in.

Application

In this use case, we will automate version management and the codebase that is merged to master branch, will be tagged for future use.

Proposed solution is as follows:

1. A very important information to accomplish Semantic Versioning is the Source Branch which is merged to the Master Branch
2. The Source Branch is obtained using a Predefined Variable of Gitlab — CI_COMMIT_TITLE
3. The format of the CI_COMMIT_TITLE will be as follows — Merge branch ‘<source_branch>’ into ‘<targer_branch>’. Eg: Merge branch ‘QA’ into ‘master’
4. The Source branch is obtained by making a string manipulation
5. MySQL is used to store the current values of the versions of Major, Minor and Patch

This solution can be explained in detail as follows:

• Establish a connection to your SQL by providing required credentials. It is always preferred to add MYSQL_HOST, MYSQL_USER and MYSQL_PASS under the variables field available in the CI/CD section of the settings panel. Once the connection is established, we can reuse the same

• The MAJOR, MINOR and PATCH values are retrieved from the DB. If it is a new entry then the new row is created by entering values as 1,0 and 0 respectively

The standard format of versioning that is followed is MAJOR.MINOR.PATCH.

• Once source branch is obtained, the Major, Minor and Patch values are updated based on the following conditions:

1. Major versions will increment by one only if the code is merged from the QA branch(Or any other branch of the choice)
2. Minor versions will be incremented by one only if the code is merged from feature/<feature_name> branch
3. Patch version will be incremented by one only if the code is merged from patch/<patch_name> branch

• For tagging a particular release, a message can be appended. This message is obtained from a file called ReleaseNote.txt within the Repository.
• Once Versions are properly updated and Tag Message is obtained, the tagging is done using git tag and git push commands as shown below:

• For tagging purposes, a user in git is very essential. Hence a user can be created and developer access can be given.
• The values will be incremented and stored back in the MySQL DB for future purpose.

The above implementation in the form of gitlab-ci file. A sample screenshot of the tagged release is attached:

An extra feature can be added to the above implementation by building and pushing the source code to any Container Registry of your choice using the same tag name that you have obtained.

And that’s a wrap! I hope you find this article easy-to-grasp and useful for your setup. Follow me on Knowledge Lens for more such content and connect with me on LinkedIn😃 .