GitLab Maintain versions of the code in GitLab CI/CD pipeline for the develop branch

Question

I would like to ensure that code merged via merge request in a GitLab from the feature branch to our develop branch has always a new unique version (gitflow strategy).

Version currently stored as the part of the code and depends on the project language: (ex: JavaScript it's package.json)

Version suppose to be used for:

• Docker image tag
• Package/code/library bundle
• Displayed to the user and added to the release notes.

I am having a few strategies in mind

Scenario 1

• Add checklist template to the merge request so reviewer has to mark checbox that version was increased.
• Additionally to the previous manual step I would like to have CI/CD step for the validation: Ex: need to check previous version of commit with a new one to ensure that pending merge request has greater version than previous. Any clues whether it's possible to determine?

Scenario 2

• CI/CD on a develop branch should automatically increase version of the package and commit. Not sure whether this possible and whether ad-hoc commit will no trigger CI/CD again. (can a problem to handle hotfixes)

I would appreciate any suggestions and your ideas. BR

Answer 1

While I generally do not recommend GitFlow these days, fully automated way to do what you ask is possible to achieve with an external system. Below I will describe how to do it with Reliza Hub (which is the one I'm developing - but you may find other options).

Here is the idea -

• You create your project in Reliza Hub and choose versioning schema, i.e. semver.
• You may also choose custom schema for feature branches (default is Branch.Micro).
• Next, you generate a project token from Reliza Hub and set it to your CI system.
• Then inside your CI, add a retrieve version step, which would call Reliza Hub for the next version. See samples of this on GitHub - https://github.com/relizaio/reliza-hub-integrations (note that for Jenkins there is now a dedicated plugin).

After doing this, version will be auto-resolved on every run and every merge. In any case it is guaranteed that every version is unique and there are no conflicts between branches.

If you want to adopt automatic increments of major version component - versus minor component - versus patch component, use Conventional Commits - https://www.conventionalcommits.org/en/v1.0.0/

Basically, if you start your commit message with fix, it would know to increment patch; if you start it with feat, it would know to increment minor.

You can also put what's called Version Pin on a specific branch - i.e. you can set it to 1.3.Micro - then regardless of anything else, inside this branch version will only be incremented within Major 1 and Minor 3.