btech.

id

GitLab Continuous
Integration (CI) Tutorial
Maximizing Software Development Efficiency with Essential
GitLab CI Mastery for DevOps Engineers

Enterprise Cloud System Integrator & Tech Professional Solution May 2024
GitLab Continuous Integration (CI) Tutorial btech.id

Table of Contents
About Boer Technology 2

Integrate Runner to GitLab 3

Integrate Gitlab CI x Sonarqube x Harbor x Trivy x ArgoCD 4

Manual Pipelining Gitlab-CI 12

Enable Monitoring Gitlab CI Pipeline 15

Semantic Release Versioning 20

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners.
GitLab Continuous Integration (CI) Tutorial btech.id

About Boer Technology

Since 2009, Boer Technology (Btech) has committed to customers from various
industries in Indonesia to continue provide the best services and solutions by
using Open-Source Software as a tool to create an environmentally friendly
company. Supported by reliable human resources, we are now focusing on Cloud,
DevOps, Security, and Tech Professional Delivery to realize an efficient and secure
company and make business running faster.

Our Services
Consulting
Our Certified Experts provide Excellent Professional Service in the form of
discussion to produce a documented plan to give the best solution for your
needs.

Implementation
Btech provides a development service for independent infrastructure or platforms
tailored to clients' needs. The implementation can be paired with training
activities and optional maintenance services.

Maintenance Support
Maintenance support provides maintenance for prevention and ticket-based
repair with a flexible Service Level Agreement. This service can be bundled with
the implementation activities if required by the clients.

Managed Service
Availability of new reliable resources takes time. Btech will help to assist the
overall technical operations in Managed Service. Btech also supports unlimited
preventive and corrective tickets for this service.

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 2
GitLab Continuous Integration (CI) Tutorial btech.id

Integrate Runner to GitLab

Install GitLab Runner Shell Executor

1. Download and Install the binary for your system
1|wget https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb
2|dpkg -i gitlab-runner_amd64.deb

2. Register runner
1|gitlab-runner register

3. Input runner specification prompt

1|Enter the GitLab instance URL (for example, https://gitlab.com/):
2|https://your-gitlab.com
3|
4|# untuk mendapatkan token masuk menu cicd > runners di your-gitlab.com
5|Enter the registration token:
6|$REGISTRATION_TOKEN
7|
8|Executor : Shell

4. Result

References
●
Install GitLab Runner

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 3
GitLab Continuous Integration (CI) Tutorial btech.id

Integrate GitLab CI x SonarQube x

Harbor x Trivy x ArgoCD
Prerequisites
●
GitLab runner shell executor installed
●
SonarQube, Harbor, Trivy, ArgoCD installed
●
Credentials set on GitLab CI/CD Variables

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 4
GitLab Continuous Integration (CI) Tutorial btech.id

Integrate GitLab CI x SonarQube

1. Create sonar-project.properties in your repository
Create a file in your repository with the name sonar-project.properties and add this
lines into it.
1|# SonarQube server
2|# See https://docs.sonarqube.org/latest/analysis/gitlab-cicd/.
3|sonar.projectKey=calculator
4|sonar.projectName=calculator
5|sonar.projectVersion=1.0
6|sonar.exclusions=vendor/**, storage/**, resources/**
7|sonar.language=python
8|sonar.sourceEncoding=UTF-8
9|sonar.host.url=<<sonarqube-url>>
10|sonar.python.version=2.7
11|#sonar.qualitygate.wait=true

2. Add SonarQube variables in your gitlab repository

1|SONAR_TOKEN : <<sonarqube-token>>

3. Add SonarQube job to GitLab CI Pipeline

1|# Sonarqube
2|Sonarqube Check:
3| stage: sonarqube
4| image:
5| name: sonarsource/sonar-scanner-cli:latest
6| entrypoint: [""]
7| variables:
8| # Defines the location of the analysis task cache
9| SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
10| # Shallow cloning needs to be disabled.
11| # See https://docs.sonarqube.org/latest/analysis/gitlab-cicd/.
12| GIT_DEPTH: 0
13| cache:
14| key: "${CI_JOB_NAME}"
15| paths:
16| - .sonar/cache
17| script:
18| - sonar-scanner -X
19| rules:
20| # SonarQube CommunityEdition only supports analyzing a single branch.
21| # So only run on main.
22| - if: '$CI_COMMIT_BRANCH == "main"'
23| when: on_success
24| - when: never

References
●
Integrating SonarQube into GitLab CI

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 5
GitLab Continuous Integration (CI) Tutorial btech.id

Integrate Gitlab CI x Harbor

1. Integrate Gitlab with Harbor

2. Add Build & Push Job to Harbor to GitLab CI Pipeline

1|variables:
2| IMAGE: "<<image-name>>"
3|
4|...
5|
6|# Build Image
7|Build:
8| stage: build
9| only:
10| - main
11| before_script:
12| - docker login $HARBOR_URL -u $HARBOR_USERNAME -p $HARBOR_PASSWORD
13| script:
14| - docker build -t $IMAGE:$CI_COMMIT_SHORT_SHA .
15| - docker push $IMAGE:$CI_COMMIT_SHORT_SHA
16|
17|# Tag the "main" branch as "latest"
18|Push latest:
19| stage: push
20| only:
21| - release
22| before_script:
23| - docker login $HARBOR_URL -u $HARBOR_USERNAME -p $HARBOR_PASSWORD
24| script:
25| - docker build -t $IMAGE:latest
26| - docker push $IMAGE:latest

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 6
GitLab Continuous Integration (CI) Tutorial btech.id

Integrate Gitlab CI x Trivy

1. Install Trivy CLI on runner node
1|sudo apt-get install wget apt-transport-https gnupg lsb-release
2|wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-
key add -
3|echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main |
sudo tee -a /etc/apt/sources.list.d/trivy.list
4|sudo apt-get update
5|sudo apt-get install trivy

2. Add Trivy Job to GitLab CI Pipeline

1|# Trivy Scan
2|Trivy Scan:
3| stage: trivy
4| only:
5| - main
6| before_script:
7| - docker login $HARBOR_URL -u $HARBOR_USERNAME -p $HARBOR_PASSWORD
8| script:
9| - trivy --version
10| - TRIVY_INSECURE=true trivy image --exit-code 0 --no-progress -f json -o trivy-scan-
report.json $IMAGE:$CI_COMMIT_SHORT_SHA
11| # Prints full report
12| - TRIVY_INSECURE=true trivy image --exit-code 0 --no-progress $IMAGE:$CI_COMMIT_SHORT_SHA

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 7
GitLab Continuous Integration (CI) Tutorial btech.id

Integrate Gitlab CI x ArgoCD

1. Install ArgoCD CLI on runner node
1|curl -sSL -o /usr/local/bin/argocd
https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
2|chmod +x /usr/local/bin/argocd

2. Add ArgoCD variables in your gitlab repository

1|ARGOCD_SERVER : <<argocd-server>>
2|ARGOCD_CREDS_USR : <<argocd-username>>
3|ARGOCD_CREDS_PSW : <<argocd-password>>

2. Add ArgoCD variables in your gitlab repository

1|variables:
2| IMAGE: "<<image-name>>"
3| APP_NAME: "calculator"
4| REPO_BRANCH: "main"
5| REPO_URL: "<<repo-url>>"
6|
7|...
8|
9|# ArgoCD Deploy
10|Argo CD:
11| stage: argocd
12| before_script:
13| - argocd login --insecure $ARGOCD_SERVER --username $ARGOCD_CREDS_USR --password
$ARGOCD_CREDS_PSW
14| script:
15| - ARGOCD_SERVER=$ARGOCD_SERVER argocd app create $APP_NAME --project default --repo
$REPO_URL --revision $REPO_BRANCH --path ./ --dest-namespace gl --dest-server
https://kubernetes.default.svc --upsert
16| - ARGOCD_SERVER=$ARGOCD_SERVER argocd --grpc-web app sync $APP_NAME --force
17| - ARGOCD_SERVER=$ARGOCD_SERVER argocd --grpc-web app wait $APP_NAME --timeout 600

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 8
GitLab Continuous Integration (CI) Tutorial btech.id

All Script
1|stages:
2| - sonarqube
3| - build
4| - push
5| - trivy
6| - argocd
7|
8|variables:
9| IMAGE: "<<image-name>>"
10| APP_NAME: "calculator"
11| REPO_BRANCH: "main"
12| REPO_URL: "<<repo-url>>"
13|
14|# Sonarqube
15|Sonarqube Check:
16| stage: sonarqube
17| image:
18| name: sonarsource/sonar-scanner-cli:latest
19| entrypoint: [""]
20| variables:
21| # Defines the location of the analysis task cache
22| SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
23| # Shallow cloning needs to be disabled.
24| # See https://docs.sonarqube.org/latest/analysis/gitlab-cicd/.
25| GIT_DEPTH: 0
26| cache:
27| key: "${CI_JOB_NAME}"
28| paths:
29| - .sonar/cache
30| script:
31| - sonar-scanner -X
32| rules:
33| # SonarQube CommunityEdition only supports analyzing a single branch.
34| # So only run on main.
35| - if: '$CI_COMMIT_BRANCH == "main"'
36| when: on_success
37| - when: never
38|
39|# Build Image
40|Build:
41| stage: build
42| only:
43| - main
44| before_script:
45| - docker login $HARBOR_URL -u $HARBOR_USERNAME -p $HARBOR_PASSWORD
46| script:
47| - docker build -t $IMAGE:$CI_COMMIT_SHORT_SHA .
48| - docker push $IMAGE:$CI_COMMIT_SHORT_SHA
49|

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 9
GitLab Continuous Integration (CI) Tutorial btech.id

All Script (cont.)

50|# Tag the "main" branch as "latest"
51|Push latest:
52| stage: push
53| only:
54| - release
55| before_script:
56| - docker login $HARBOR_URL -u $HARBOR_USERNAME -p $HARBOR_PASSWORD
57| script:
58| - docker build -t $IMAGE:latest
59| - docker push $IMAGE:latest
60|
61|# Trivy Scan
62|Trivy Scan:
63| stage: trivy
64| only:
65| - main
66| before_script:
67| - docker login $HARBOR_URL -u $HARBOR_USERNAME -p $HARBOR_PASSWORD
68| script:
69| - trivy --version
70| - TRIVY_INSECURE=true trivy image --exit-code 0 --no-progress -f json -o trivy-
scan-report.json $IMAGE:$CI_COMMIT_SHORT_SHA
71| # Prints full report
72| - TRIVY_INSECURE=true trivy image --exit-code 0 --no-progress $IMAGE:
$CI_COMMIT_SHORT_SHA
73|
74|# ArgoCD Deploy
75|Argo CD:
76| stage: argocd
77| before_script:
78| - argocd login --insecure $ARGOCD_SERVER --username $ARGOCD_CREDS_USR --password
$ARGOCD_CREDS_PSW
79| script:
80| - ARGOCD_SERVER=$ARGOCD_SERVER argocd app create $APP_NAME --project default --
repo $REPO_URL --revision $REPO_BRANCH --path ./ --dest-namespace gl --dest-server
https://kubernetes.default.svc --upsert
81| - ARGOCD_SERVER=$ARGOCD_SERVER argocd --grpc-web app sync $APP_NAME --force
82| - ARGOCD_SERVER=$ARGOCD_SERVER argocd --grpc-web app wait $APP_NAME --timeout 600

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 10
GitLab Continuous Integration (CI) Tutorial btech.id

Result

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 11
GitLab Continuous Integration (CI) Tutorial btech.id

Manual Pipelining GitLab-CI

Provisioning Stack
If you want to provisioning all devsecops stack, you can refer this article.

This is template for manual Pipelining YAML

This is contains :
●
SonarQube
●
Harbor
●
Helm
●
Helm Chart
●
ArgoCD
●
Approval to Telegram
1|stages:
2| #- sonarqube
3| - build
4| - push
5| #- trivy
6| - push-chart
7| - approval
8| - argocd
9|
10|variables:
11| REPO_URL: "https://your-gitlab.com/boutique/frontend.git"
12| REPO_URL_2: "https://your-gitlab.com/boutique/frontend"
13| IMAGE: "your-private.registry.com/boutique/frontend"
14|
15| # Helm
16| HELM_REPO: "http://192.168.3.99:8080"
17| APP_NAME: "frontend"
18|
19| # ArgoCD
20| ARGOCD_SERVER: "192.168.3.52"
21| ARGOCD_STAGING_PROJECT: "boutique-staging"
22| ARGOCD_RELEASE_PROJECT: "boutique"
23|
24|before_script:
25| - export TAGS=$(git tag --sort=-creatordate | head -n 1)
26| - export STAGING=staging-$TAGS
27| - export RELEASE=$TAGS
28| - export HELM_CHART_STAGING_VERSION=$TAGS-staging
29| - export HELM_CHART_RELEASE_VERSION=$TAGS
30| - export HELM_STAGING_VERSION=$STAGING
31| - export HELM_APP_VERSION=$RELEASE
32| - export ARGOCD_APP_STAGING=$APP_NAME-staging
33| - export ARGOCD_APP_RELEASE=$APP_NAME
34| - echo Image Staging = $STAGING && echo Image Release = $RELEASE
35| - echo Helm Chart Staging = $HELM_CHART_STAGING_VERSION && echo Helm Chart Release = $HELM_CHART_RELEASE_VERSION
&& echo Helm Staging Version = $HELM_STAGING_VERSION
36| - echo ArgoCD App Staging = $ARGOCD_APP_STAGING && echo ArgoCD App Release = $ARGOCD_APP_RELEASE
37| - docker login $HARBOR_URL -u $HARBOR_USERNAME -p $HARBOR_PASSWORD
38|

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 12
GitLab Continuous Integration (CI) Tutorial btech.id

39|# Sonarqube
40|#Sonarqube Check:
41|# stage: sonarqube
42|# image:
43|# name: sonarsource/sonar-scanner-cli:latest
44|# entrypoint: [""]
45|# variables:
46|# SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
47|# GIT_DEPTH: 0
48|# cache:
49|# key: "${CI_JOB_NAME}"
50|# paths:
51|# - .sonar/cache
52|# script:
53|# - sonar-scanner -X
54|# rules:
55|# - if: '$CI_COMMIT_BRANCH == "staging"'
56|# when: on_success
57|# - when: never
58|
59|# Build Image
60|Build Staging:
61| stage: build
62| only:
63| - staging
64| script:
65| - echo frontend Staging version = $STAGING
66| - docker build -t $IMAGE:$STAGING .
67| - docker push $IMAGE:$STAGING
68|
69|# Tag the "release" branch as "latest"
70|Build Release:
71| stage: push
72| only:
73| - release
74| script:
75| - docker pull $IMAGE:$STAGING
76| - docker tag $IMAGE:$STAGING $IMAGE:$RELEASE
77| - docker tag $IMAGE:$STAGING $IMAGE:latest
78| - docker push $IMAGE:$RELEASE
79| - docker push $IMAGE:latest
80|
81|# Trivy Scan
82|#Trivy Scan:
83|# stage: trivy
84|# script:
85|# - trivy --version
86|# - TRIVY_INSECURE=true trivy image --exit-code 0 --no-progress -f json -o trivy-scan-report.json $IMAGE
87|# # Prints full report
88|# - TRIVY_INSECURE=true trivy image --exit-code 0 --no-progress $IMAGE
89|
90|# Push Chart
91|Push Chart Staging:
92| stage: push-chart
93| only:
94| - staging
95| script:
96| - sed -i "s+{{CHART_VERSION}}+$HELM_CHART_STAGING_VERSION+g" ./frontend/Chart.yaml
97| - sed -i "s+{{IMAGE_VERSION}}+$HELM_STAGING_VERSION+g" ./frontend/Chart.yaml
98| - helm repo add chartmuseum $HELM_REPO --force-update
99| - helm cm-push frontend chartmuseum --force
100| - helm repo update
101|

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 13
GitLab Continuous Integration (CI) Tutorial btech.id

102|
Push Chart:
103| stage: push-chart
104| only:
105| - release
106| script:
107| - sed -i "s+{{CHART_VERSION}}+$HELM_CHART_RELEASE_VERSION+g" ./frontend/Chart.yaml
108| - sed -i "s+{{IMAGE_VERSION}}+$HELM_APP_VERSION+g" ./frontend/Chart.yaml
109| - helm repo add chartmuseum $HELM_REPO --force-update
110| - helm cm-push $APP_NAME chartmuseum --force
111| - helm repo update
112|
113|
# Approval Staging
114|
Approval Staging:
115| stage: approval
116| only:
117| - staging
118| environment:
119| name: approval-staging
120| url: $REPO_URL
121| script:
122| - curl -s -X POST https://api.telegram.org/bot$TELE_TOKEN/sendMessage -d chat_id=$TELE_CHAT_ID -d
parse_mode=markdown -d text="Dear Team *CusEx*, Please Approve Deployment of * $APP_NAME * on Branch *Staging*. Please
goes to $REPO_URL_2/-/environments to *Accept.*"
123|
124|
# Approval Release
125|
Approval Release:
126| stage: approval
127| only:
128| - release
129| environment:
130| name: approval-release
131| url: $REPO_URL
132| script:
133| - curl -s -X POST https://api.telegram.org/bot$TELE_TOKEN/sendMessage -d chat_id=$TELE_CHAT_ID -d
parse_mode=markdown -d text="Dear Team *CusEx*, Please Approve Deployment of * $APP_NAME * on Branch *Release*. Please
goes to $REPO_URL_2/-/environments to *Accept.*"
134|
135|
# ArgoCD Deploy
136|
Deploy Staging to ArgoCD:
137| stage: argocd
138| rules:
139| - if: '$CI_COMMIT_BRANCH == "staging"'
140| when: manual
141| environment:
142| name: staging
143| url: https://cx-boutique-stg.btech.id
144| script:
145| - argocd login --insecure $ARGOCD_SERVER --username $ARGOCD_CREDS_USR --password $ARGOCD_CREDS_PSW
146| - argocd app create $ARGOCD_APP_STAGING --project $ARGOCD_STAGING_PROJECT --repo $HELM_REPO --helm-chart $APP_NAME
--revision $HELM_CHART_STAGING_VERSION --dest-namespace boutique-staging --dest-server https://kubernetes.default.svc --
annotations notifications.argoproj.io/subscribe.on-sync-succeeded.teams=TeamsBTech --upsert
147| - ARGOCD_SERVER=$ARGOCD_SERVER argocd --grpc-web app sync $ARGOCD_APP_STAGING --force
148| - ARGOCD_SERVER=$ARGOCD_SERVER argocd --grpc-web app wait $ARGOCD_APP_STAGING --timeout 600
149|
150|
# ArgoCD Deploy
151|
Deploy Release to ArgoCD:
152| stage: argocd
153| rules:
154| - if: '$CI_COMMIT_BRANCH == "release"'
155| when: manual
156| environment:
157| name: release
158| url: https://cx-boutique.btech.id
159| script:
160| #- argocd login --insecure $ARGOCD_SERVER --username $ARGOCD_CREDS_USR --password $ARGOCD_CREDS_PSW
161| - argocd app create $ARGOCD_APP_RELEASE --project $ARGOCD_RELEASE_PROJECT --repo $HELM_REPO --helm-chart $APP_NAME
--revision $HELM_CHART_RELEASE_VERSION --dest-namespace boutique --dest-server https://kubernetes.default.svc --
annotations notifications.argoproj.io/subscribe.on-sync-succeeded.teams=TeamsBTech --upsert
162| - ARGOCD_SERVER=$ARGOCD_SERVER argocd --grpc-web app sync $ARGOCD_APP_RELEASE --force
163| - ARGOCD_SERVER=$ARGOCD_SERVER argocd --grpc-web app wait $ARGOCD_APP_RELEASE --timeout 600

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 14
GitLab Continuous Integration (CI) Tutorial btech.id

Enable Monitoring Gitlab CI Pipeline

Project
Gitlab-CI-Pipelines-Exporter

Execution
1|git clone https://github.com/mvisonneau/gitlab-ci-pipelines-exporter.git
2|cd gitlab-ci-pipelines-exporter/examples/quickstart

Change gitlab-ci-pipelines-exporter.yml config

1|nano gitlab-ci-pipelines-exporter.yml
2|
3|---
4|log:
5| level: debug
6|
7|gitlab:
8| url: https://<gitlab-url>
9| token: <gitlab-token>
10|
11|
# Pull jobs related metrics on all projects
12|
project_defaults:
13| pull:
14| pipeline:
15| jobs:
16| enabled: true
17|
18|
# Example public projects to monitor
19|
projects:
20| - name: team-cusex/boutique/adservice
21| - name: team-cusex/boutique/cartservice
22| - name: team-cusex/boutique/checkoutservice
23| - name: team-cusex/boutique/currencyservice
24| - name: team-cusex/boutique/emailservice
25| - name: team-cusex/boutique/frontend
26| - name: team-cusex/boutique/paymentservice
27| - name: team-cusex/boutique/productcatalogservice
28| - name: team-cusex/boutique/recommendationservice
29| - name: team-cusex/boutique/shippingservice
30| - name: team-cusex/boutique/loadgenerators
31| - name: team-cusex/boutique/testing
32| - name: team-cusex/boutique/testing-go
33|
---

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 15
GitLab Continuous Integration (CI) Tutorial btech.id

Edit prometheus config.yml

1|global:
2| scrape_interval: 15s
3| evaluation_interval: 15s
4|
5|scrape_configs:
6| - job_name: 'gitlab-ci-pipelines-exporter'
7| scrape_interval: 10s
8| scrape_timeout: 5s
9| static_configs:
10| - targets: ['192.168.2.26:8080']

Deploy
1|docker-compose up -d

gitlab-ci-pipelines-exporter : http://localhost:8080/metrics

prometheus : http://localhost:9090

grafana : http://localhost:3000 (creds : admin/admin)

Checkout prometheus targets and available metrics

http://192.168.2.26:9090/targets

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 16
GitLab Continuous Integration (CI) Tutorial btech.id

http://192.168.2.26:9090/new/graph

You can then validate that you get the expected values for your projects metrics, eg
gitlab_ci_pipeline_status:
http://192.168.2.26:9090/new/graph? g0.expr=gitlab_ci_pipeline_status&g0.tab=1&g0.stacked=0&g0.range_input=1h

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 17
GitLab Continuous Integration (CI) Tutorial btech.id

Checkout the grafana example dashboards

Example dashboards should be available at these addresses:

●
Pipelines dashboard
http://192.168.2.26:3000/d/gitlab_ci_pipelines

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 18
GitLab Continuous Integration (CI) Tutorial btech.id

●
Jobs dashboard
http://192.168.2.26:3000/d/gitlab_ci_jobs

●
Environments / deployments dashboard
http://192.168.2.26:3000/d/gitlab_ci_environment_deployments

References
●
Gitlab CI Pipeline Exporter

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 19
GitLab Continuous Integration (CI) Tutorial btech.id

Semantic Release Versioning

Semantic versioning is a set of rules that can be followed or not followed, and the
job of a semantic versioning standard is simply to help make versioning clearer.

Example

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 20
GitLab Continuous Integration (CI) Tutorial btech.id

Flow (+-)

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 21
GitLab Continuous Integration (CI) Tutorial btech.id

Requirements
A. Repo : https://your-gitlab.com/testing.git

B. GitLab Token and set to CI/CD Variables (Protected) grant the api and the write_repository scopes to the token.

C. NPM Token and set to CI/CD Variables (Protected)

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 22
GitLab Continuous Integration (CI) Tutorial btech.id

D. Commitizen. Ref : https://pypi.org/project/commitizen/

1|pip install commitizen

Commitizen is a tool designed for teams. Its main purpose is to define a standard way of
committing rules and communicating it (using the cli provided by commitizen). The reasoning
behind it is that it is easier to read, and enforces writing descriptive commits. Besides that,
having a convention on your commits makes it possible to parse them and use them for
something else, like generating automatically the version or a changelog.

E. Protect Branch. https://docs.gitlab.com/ee/user/project/protected_branches.html

Behind the scenes

If you’re curious to know what happens when a pipeline is triggered, here’s the detail:

1. when a new commit happens (either via git push or a merge) GitLab starts a new
pipeline.
2. when the pipeline runs the job that starts semantic-release, the process goes
through each release steps for each plugin, in the order they are configured.
3. the latest release is determined by inspecting the tags and messages of commits
4. the analyzeCommits (the only required step) determines if a new release has to be
created and, if so, which type.
5. each plugin performs its core tasks, like generating release notes, changelogs
or creating tags. Change logs are interpreted by default based on the Angular
commit message conventions.
6. the release is then published and notified by plugins.

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 23
GitLab Continuous Integration (CI) Tutorial btech.id

How does semantic-release decide when to tag a

version or not?
semantic-release makes this decision based on:
• the branch that was committed (either via a merge request or a push) must be
configured in the workflow configuration (the branches section of the configuration file)
• the format of the commit message or the title of the merge request must match one of
the formats configured for the @semantic-release/commit-analyzer plugin (which is
usually configured to use presets

Create .releaserc.yml
.releaserc.yml

1|plugins:
2|- "@semantic-release/commit-analyzer"
3|- "@semantic-release/release-notes-generator"
4|- - "@semantic-release/exec"
5| - verifyReleaseCmd: "echo ${nextRelease.version} > VERSION.txt"
6|- - "@semantic-release/changelog"
7| - changelogFile: CHANGELOG.md
8|- - "@semantic-release/gitlab"
9| - gitlabUrl: https://your-gitlab.com/
10|- - "@semantic-release/git"
11| - assets:
12| - CHANGELOG.md
13| - VERSION.txt
14| message: |-
15| chore(release): ${nextRelease.version} [skip ci]
16|
17| ${nextRelease.notes}
18|
19|branches:
20|- "main"
21|- "+([0-9])?(.{+([0-9]),x}).x"
22|- name: "rc"
23| prerelease: "rc"

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 24
GitLab Continuous Integration (CI) Tutorial btech.id

.gitlab-ci.yml
1|stages:
2| - fetch-version
3| - build
4| - push
5| - release
6|
7|variables:
8| IMAGE: "your-private.registry.com/calculator/calculator"
9|
10|
before_script:
11| - docker login $HARBOR_URL -u $HARBOR_USERNAME -p $HARBOR_PASSWORD
12|
13|
fetch-semantic-version:
14| # Requires Node >= 10.13 version
15| image: node:13
16| stage: fetch-version
17| only:
18| refs:
19| - main
20| - rc
21| - /^(([0-9]+)\.)?([0-9]+)\.x/ # This matches maintenance branches
22| - /^([0-9]+)\.([0-9]+)\.([0-9]+)(?:-([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?(?:\+[0-9A-Za-z-]+)?$/ # This matches pre-releases
23| script:
24| - npm install @semantic-release/gitlab @semantic-release/exec @semantic-release/changelog @semantic-release/commit-analyzer
@semantic-release/release-notes-generator @semantic-release/npm @semantic-release/git
25| - npx semantic-release --generate-notes false --dry-run
26| artifacts:
27| paths:
28| - VERSION.txt
29|
30|
Build:
31| stage: build
32| only:
33| - rc
34| before_script:
35| - export TAGS=$(cat VERSION.txt)
36| script:
37| - docker build -t $IMAGE:$TAGS .
38| - docker push $IMAGE:$TAGS
39|
40|
## Tag the "main" branch as "latest"
41|
Push latest:
42| stage: push
43| only:
44| - main
45| before_script:
46| - export TAGS=$(cat VERSION.txt)
47| script:
48| - docker build -t $IMAGE:$TAGS .
49| - docker tag $IMAGE:$TAGS $IMAGE:latest
50| - docker push $IMAGE:$TAGS
51| - docker push $IMAGE:latest
52|
53|
release:
54| image: node:13
55| stage: release
56| only:
57| refs:
58| - main
59| - rc
60| # This matches maintenance branches
61| - /^(([0-9]+)\.)?([0-9]+)\.x/
62| # This matches pre-releases
63| - /^([0-9]+)\.([0-9]+)\.([0-9]+)(?:-([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?(?:\+[0-9A-Za-z-]+)?$/
64| script:
65| - npm install @semantic-release/gitlab @semantic-release/exec @semantic-release/changelog @semantic-release/commit-analyzer
@semantic-release/release-notes-generator @semantic-release/npm @semantic-release/git
66| - npx semantic-release
67| artifacts:
68| paths:
69| - CHANGELOG.md

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 25
GitLab Continuous Integration (CI) Tutorial btech.id

Review
It looks like a lot of stuff. What we do here:
1. define a new stage in the pipeline named fetch-version. This stage runs at the
beginning of the pipeline to fetch or generate the version number and make it available
2. define a new job fetch-semantic-version that runs at the fetch-version stage only
on the branches managed by semantic-release. This time we use the options --generate-
notes false --dry-run to avoid applying any change. However this still generates the
VERSION.txt file because of the semantic-release configuration we have in place
3. produce the VERSION.txt file in both jobs (of course you can use any other name) and
publish it as an artifact because it needs to be available across different build jobs
4. define another job build that build a docker image using the value from VERSION.txt
regardless of how and when it was generated
5. define a new job 'release' that runs semantic-release and publish ChangeLog to our repo

Default rules matching

https://github.com/semantic-release/commit-analyzer

If a commit doesn’t match any rule in releaseRules it will be evaluated against the default
release rules.

With the previous example:

●
Commits with a breaking change will be associated with a major release.
●
Commits with type feat will be associated with a minor release.
●
Commits with type fix will be associated with a patch release.
●
Commits with type perf will be associated with a patch release.
●
Commits with scope no-release will not be associated with a release type even if they
have a breaking change or the type feat, fix or perf.

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 26
GitLab Continuous Integration (CI) Tutorial btech.id

No rules matching
If a commit doesn`t match any rules in releaseRules or in default release rules then no
release type will be associated with the commit.

With the previous example:

●
Commits with type style will not be associated with a release type.
●
Commits with type test will not be associated with a release type.
●
Commits with type chore will not be associated with a release type.

Try to Use pre-release branch

Pretend to be a bug fix on rc branch.

Change branch into rc

1|git checkout -b rc

Edit app/templates/calculator.html
1|...
2| <h3 class="text-muted">Simple Scientific Calculator (v1.2.1)</h3>
3|...

Use Fix Message Commit to increase patch release version

1|git add .
2|cz commit

Note: we use fix to add patch version. if Breaking Change set to Yes, it will Correlates
with MAJOR in SemVer
1|git push origin rc

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 27
GitLab Continuous Integration (CI) Tutorial btech.id

Results

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 28
GitLab Continuous Integration (CI) Tutorial btech.id

Merge to main
Pull on rc branch first
1|git pull

Merge squash to prevent message commit

1|git checkout main
2|git merge --squash rc

Commit with cz commit and push

1|git add .
2|cz commit
3|git push origin main

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 29
GitLab Continuous Integration (CI) Tutorial btech.id

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 30
GitLab Continuous Integration (CI) Tutorial btech.id

Results
●
Rc Version Url : http://192.168.3.141:5000/
●
Main Version Url : http://192.168.3.140:5000/

CHANGELOG.md

References
●
https://semver.org/
●
https://github.com/semantic-release/semantic-release
●
https://www.youtube.com/watch?v=QZdY4XYbqLI&list=LL&index=14
●
https://levelup.gitconnected.com/semantic-versioning-and-release-automation-on-gitlab-9ba16af0c21
●
https://medium.com/nerd-for-tech/auto-bump-apps-versions-and-releases-using-gitlab-pipeline-e32f1d7fa3ee
●
https://repository.prace-ri.eu/git/help/ci/examples/semantic-release.md
●
https://faun.pub/git-flow-and-semantic-release-with-gitlab-be54b2c64818
●
https://stackoverflow.com/questions/70790587/semantic-release-not-accepting-gitlab-token-on-gitlab-private-
repository
●
https://itnext.io/automate-your-releases-versioning-and-release-notes-with-semantic-release-d5575b73d986

© 2024 Boer Technology. All rights reserved. All trademarks are the property of their respective owners. 31
 btech.id

GitLab Continuous
Integration (CI) Tutorial
Maximizing Software Development Efficiency with
Essential GitLab CI Mastery for DevOps Engineers
 btech.id

Contact Us

Boer Technology
Komplek Ruko Pandu Raya No. 14, Jl. Achmad
Adnawijaya, Bogor, West Java, Indonesia 16152

+62 811-1123-242 [email protected]