Running CI/CD Pipeline with GitLab CI

GitLab allows us to deploy CI/CD pipeline runners on our own resources within our environment. This option is available not only for the self-hosted plan but also for the cloud service plan (gitlab.com). With this setup, unlike GitHub Action, we can avoid incurring additional costs for extended pipeline runtime. This is because we can deploy the runner on an on-demand server and optimize its usage.

GitLab CI offers several options for setting up resources to run CI/CD pipelines. A runner can be configured to handle jobs for specific groups or projects using designated tags. It can also be set to use different executors, such as Shell, Docker, Kubernetes, or VirtualBox. A comparison table of the supported executors is available in the executor documentation. Some executors offer greater flexibility and ease of use, while others may be more rigid but enhance server security.

Installing the runner in our machine

For example, we will deploy the runner on an Ubuntu server. It is recommended to use a separate machine from the one hosting the GitLab server. Detailed instructions can be found in the runner documentation.

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
sudo apt-get install gitlab-runner

Additionally, we have to install Docker because we will use it as the executor in this process.

Registering the runner on our GitLab

We will configure the runner to handle jobs only from a specific group using designated tags. In this example, I use the latest registration mechanism available in GitLab Runner 15.10 or later.

• Visit the control panel of the desired group and choose the Build > Runners menu.
• Choose the "New group runner" option.
• Fill in the required fields including the tags field.
• Copy the command generated after submitting the form that contains the registration token.

Linking the runner with the GitLab CI instance

Next, return to the machine where the runner is installed and run the command generated in the previous step. The command will look like the example below.

gitlab-runner register --url https://YOUR_GITLAB_HOST --token glrt-xxx

When running the command, you will be prompted to answer a few questions. For the executor, you can type "docker", and for the default image, you can select "ubuntu:22.04". Detailed instructions for registering the runner are available in the runner configuration documentation.

Configuring the runner

Before the runner can function properly, we need to update certain values in the configuration file located at "/etc/gitlab-runner/config.toml". First, generate a Personal Access Token or a group-level token to allow the runner to pull the contents of the repository in the group. Then, input the token value into the configuration as shown in the example below.

[[runners]]
  name = "something"
  # ...
  executor = "docker"
  clone_url = "https://gitlab-ci-token:YOUR_PAT_OR_GROUP_TOKEN@YOUR_GITLAB_HOST"
  # ...
  [runners.docker]
    image = "ubuntu:22.04"
    pull_policy = "if-not-present"

Lastly, we must restart the runner with this command: gitlab-runner restart.

Configuring the CI/CD pipeline in our project

In GitLab CI, the pipeline script is stored in the ".gitlab-ci.yml" file within the project repository. Since the runner is configured to handle jobs with specific tags, each job in the pipeline script must be assigned the appropriate tag, as shown in the example below.

stages:
  - build
  - deploy

build-job:
  tags:
    - YOUR_TAG
  stage: build
  script:
    - echo "Compile complete."

deploy-job:
  tags:
    - YOUR_TAG
  stage: deploy
  script:
    - echo "Application successfully deployed."

After we push the update, we can check the status on the "Build > Pipelines" menu in our project repository.