Use case: Building the Docker image with a new version number
Posted: Sat Jan 25, 2025 6:33 am
The scope is optional and is written in brackets, where we can refer to a ticket number from our project management tool. In the body we briefly describe what this commit changes. The special thing is that we can deduce from the different types how the version will change. For example, the following commit message will lead to an increase in the minor version:
GitLab pipelines to automate the creation of a semantic version
Pipelines are an essential part of continuous integration. A pipeline consists of stages and jobs. A stage describes when jobs should be executed, for example when there is a merge request for automatic tests or after a merge to the main branch.
Multiple jobs can exist in a stage. A job contains code or can execute scripts, e.g. we can check the code quality of the branch. Jobs in a stage must be successful, that is, they must end with exit code 0, so that the pipeline can move on to the next stage or exit successfully.
To automatically create a new version from the commit messages, first create it .gitlab-ci.yaml-Dateiif it does not already exist.
Versioning-StageThe and a job for the are created Versioning-Stage. The job requires a Node.js Docker image as a basis. For this, the GitLab runner must have access to the Docker Engine.
To set this up, please follow the GitLab documentation on the Docker executor .
First, create a new stage and a new job that will create the semantic version.
The stagesobject can have a list of stages. Once you have created the stage, you can now define jobs for the stage.
You create a new job build-tag. The job is defined as follows and will bahrain consumer email list create a new version for us:
In the job, we install the NPM package Semantic-Release and install Git in the Node.js Docker image. Semantic-Release does the work for us and takes care of determining the next version number.
The advantage is that Semantic Release takes human emotions out of the versioning process and follows clear rules, the rules of semantic versioning. However, we can specify which commit message types the package should react to in order to define a new version.
To define rules about which types Semantic-Release should react to, one must .releaserc.json Dateiexist in the current execution path. Here you can see the configuration reference of Semantic-Release .
My configuration is stored in an environment variable $RELEASE_RC. This variable is stored in the CI/CD settings of the repository.
You also need an environment variable called $GITLAB_TOKEN. The variable $GITLAB_TOKENcontains a token for accessing the repository. You can read how to create an access token here . Semantic-Release looks for this variable to publish a Git tag in your repository. A Git tag is a function for marking points in a version history as important.
Semantic-Release first checks whether there are version tags in the Git repository. When a version is created, Semantic-Release sets a new Git tag that contains the version. If a corresponding version tag is found, only all commits up to this tag are examined. The commit message is then examined for all commits found. The version number can then be calculated based on the commit message types used. The new semantic version is then published as a Git tag in the repository.
If no tag is found, a Git tag with the version is automatically v1.0.0created. The initial version can be passed to Semantic-Release in the configuration.
To create a Docker image based on our code, we define a new stage named deployand a new job named build_docker_image. The job should be executed whenever a new Git tag is created in the repository and the name of the tag is a semantic version number.
The Git tag with the semantic version number should have been created in the previous step. If no new Git tag was created, the type of the commit is wrong or the structure of the commit message was not followed.
GitLab pipelines to automate the creation of a semantic version
Pipelines are an essential part of continuous integration. A pipeline consists of stages and jobs. A stage describes when jobs should be executed, for example when there is a merge request for automatic tests or after a merge to the main branch.
Multiple jobs can exist in a stage. A job contains code or can execute scripts, e.g. we can check the code quality of the branch. Jobs in a stage must be successful, that is, they must end with exit code 0, so that the pipeline can move on to the next stage or exit successfully.
To automatically create a new version from the commit messages, first create it .gitlab-ci.yaml-Dateiif it does not already exist.
Versioning-StageThe and a job for the are created Versioning-Stage. The job requires a Node.js Docker image as a basis. For this, the GitLab runner must have access to the Docker Engine.
To set this up, please follow the GitLab documentation on the Docker executor .
First, create a new stage and a new job that will create the semantic version.
The stagesobject can have a list of stages. Once you have created the stage, you can now define jobs for the stage.
You create a new job build-tag. The job is defined as follows and will bahrain consumer email list create a new version for us:
In the job, we install the NPM package Semantic-Release and install Git in the Node.js Docker image. Semantic-Release does the work for us and takes care of determining the next version number.
The advantage is that Semantic Release takes human emotions out of the versioning process and follows clear rules, the rules of semantic versioning. However, we can specify which commit message types the package should react to in order to define a new version.
To define rules about which types Semantic-Release should react to, one must .releaserc.json Dateiexist in the current execution path. Here you can see the configuration reference of Semantic-Release .
My configuration is stored in an environment variable $RELEASE_RC. This variable is stored in the CI/CD settings of the repository.
You also need an environment variable called $GITLAB_TOKEN. The variable $GITLAB_TOKENcontains a token for accessing the repository. You can read how to create an access token here . Semantic-Release looks for this variable to publish a Git tag in your repository. A Git tag is a function for marking points in a version history as important.
Semantic-Release first checks whether there are version tags in the Git repository. When a version is created, Semantic-Release sets a new Git tag that contains the version. If a corresponding version tag is found, only all commits up to this tag are examined. The commit message is then examined for all commits found. The version number can then be calculated based on the commit message types used. The new semantic version is then published as a Git tag in the repository.
If no tag is found, a Git tag with the version is automatically v1.0.0created. The initial version can be passed to Semantic-Release in the configuration.
To create a Docker image based on our code, we define a new stage named deployand a new job named build_docker_image. The job should be executed whenever a new Git tag is created in the repository and the name of the tag is a semantic version number.
The Git tag with the semantic version number should have been created in the previous step. If no new Git tag was created, the type of the commit is wrong or the structure of the commit message was not followed.