Back to the main page

GitLab CI/CD (shell executor example)

Brief introduction

This page has very short and limited info, it's intended to be just quick "reminder" how to start with GitLab CI/CD (shell executor example).

GitLab CI (Continuous Integration) and CD (Continuous Deployment) is GitLab service (this example is GitLab v14.0.1 on-prem), this service in general builds, tests, deploys/delivers a "software/app" when a code is pused to GiLab.
Scripts for building, testing, etc. are basically "jobs", jobs can be grouped in "stages" (run in specified order), andf this is a pipeline.

The file .gitlab-ci.yml

GitLab offeres Auto DevOps (doesn't required this file), but if you want own CI/CD, this file has to be used.
The file .gitlab-ci.yml is CI/CD configuration, and has to be placed in the root of your gitlab repository (or project).

GitLab Runner

GitLab Runner application works with GitLab CI/CD to run jobs in a pipeline. It doesn't run on GitLab server, but on some other machine, here in this example we use OracleLinux 8.

The gitlab-runner is installed via yum/dnf from repository. 
[runner_gitlab-runner]
name=runner_gitlab-runner
baseurl=https://packages.gitlab.com/runner/gitlab-runner/ol/8/$basearch
repo_gpgcheck=1
gpgcheck=1
enabled=1
gpgkey=https://packages.gitlab.com/runner/gitlab-runner/gpgkey
       https://packages.gitlab.com/runner/gitlab-runner/gpgkey/runner-gitlab-runner-4C80FB51394521E9.pub.gpg
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

The installed version of gitlab-runner is v15.5.1, with installation of dependencies like git, git-core, perl-Git and similar. It also creates gitlab-runner user and group. At the end, verify that gitlab-runner service is enabled and running. See "gitlab-runner --help" for many of its commands/options.

GitLab server setup

Via GitLab web page, go to your Project (git repo) - Settings - CI/CD. Do not enable Auto DevOps.
Expand Runners section. See info how to "Set up a specific runner manually". Note URL and registration token (ex. spjXy5TgxV13kTjVXA).

GitLab runner setup

Now, register gitlab runner on OL8 machine. 
[root@my-ol8 ~]# gitlab-runner register --url https://my-gitlab.domain.com/ --registration-token spjXy5TgxV13kTjVXA

Runtime platform        arch=x86_64 os=linux version=15.5.1
Running in system-mode.

Enter the GitLab instance URL (for example, https://gitlab.com/):
[https://my-gitlab.domain.com/]: press enter to accept defaults
Enter the registration token:
[spjXy5TgxV13kTjVXA]:
Enter a description for the runner:
[my-ol8]:
Enter tags for the runner (comma-separated):
test, dev, qa (just some examples)
Enter optional maintenance note for the runner:
Runner for testing
Registering runner... succeeded    runner=spjXy_5T
Enter an executor: ssh, virtualbox, instance, kubernetes, docker-ssh, parallels, shell, docker+machine, docker:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Configuration (with the authentication token) was saved in "/etc/gitlab-runner/config.toml"

This runner now shows in GitLab server, Runners section, as "Available specific runners".

Here shell executor is used, so OL8 machine will run jobs' scripts in the OS shell. If we use docker executor, then OL8 will need to have Docker installed, and will run jobs inside containers.

The runner cfg file is /etc/gitlab-runner/config.toml. 
log_level = "debug"
log_format = "text"
concurrent = 1
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "my-ol8.domain.com"
  url = "https://my-gitlab.domain.com/"
  id = 2832
  token = "nwBZK1JS15netcL5aUrd"
  token_obtained_at = 2022-11-18T16:46:47Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "shell"

The file can be manually edited, restart gitlab-runner service after edit, make sure it starts. If not, must be some errors in toml file.

Pipeline

This is for shell executor.
Gitlab runner (OL8) checks out code (it's some Ansible role) repo inside local directory /builds/some-tmp-name/group/project (Example: /builds/nwBZK1JS/0/LabOps/test-admin ), and tries to cd into it.
From there it tries to run scripts with any arguments passed to it.

This is .gitlab-ci.yml file (simple example) with three stages, where only test stage (has two jobs) does some linting (of Ansible role code). As per this code, the OL8 machine (runner) has python virtual environment, that we use for both yamllint and ansible-lint. 
---
# GitLab predefined variables
# https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
# Keywords for .gitlab-ci.yml
# https://docs.gitlab.com/ee/ci/yaml/

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  before_script:
    - echo "My on-prem GitLab server version is $CI_SERVER_VERSION_MAJOR"
    - echo "My GitLab project/repo is $CI_PROJECT_TITLE"
    - echo "My Runner version is $CI_RUNNER_VERSION"
  script:
    - echo "Nothing to build!"

yamllint-job:
  stage: test
  script:
    - echo "Start my python virtual environment ..."
    - source /python-venv/molecule/bin/activate
    - echo "Start yamllint ..."
    - yamllint .
    - echo "Done with yamllint ..."

ansible-lint-job:
  stage: test
  script:
    - echo "Start again my python virtual environment ..."
    - source /python-venv/molecule/bin/activate
    - echo "Start ansible-lint ..."
    - ansible-lint .
    - echo "Done with ansible-lint ..."

deploy-job:
  stage: deploy
  script:
    - echo "Nothing to deploy ..."
...


This is when test job, linting check failed.


See errors, correct then, git add/commit, git psuh, and this is passed pipeline.


From this beginning, more advanced work can be done.

Back to the main page