GitLab pipelines

A gitlab(or any other git implementation pipeline) ensures that code is run automaticly as an update to the repository occurs. To automate this within gitlab there are a few conditions that have to be met:

  • A gitlab runner is configured
  • The runner has to be availlable for the group/project
  • The repository has a pipeline configured (.gitlab-ci.yml)

Group runner on GitLab project

To be able to use a pipline, a gitlab runner must be availlable in the project: runner This can be found under: Settings/"CI/CD"/runners
As show in the picture above.. "availlable shared runners: 1"
There is a runner availlable to run the pipeline code that is in the file .gitlab-ci.yml

If the above says "0", there is no runner availlable, you should ask the gitlab engineer to add a runner for your project/group.

GitLab runner

A gitlab runner is a machine/container that will run the code that is written in the gitlab-ci.yml.
It will evaluate the code in this file and run only the appropriate steps according to the contents of the file.
The runner is a service that logs in into gitlab and polls every few seconds if there is a job to be run.
Each runner has a "Tag"(eg. name) that can be specified in the .gitlab-ci.yml file, so you can control which runner will execute the pipeline code (if that runner is enabled for your project).

A runner is an instance that is NOT within gitlab itself and must be configured on a separate system.
In the online edition of gitlab, these are already present and can be used by anyone (be aware of the risks when opening local ports for access from a online runner).

In an on-premise situation, we have to accomplish this ourselves and define our own runners.
These can run on Docker, Kubernetes, OpenShift or even a simple VM.

The implementation of a gitlab runner is well documented on gitlab.com.
For a gitlab runner on OpenShift there are a few things to bare in mind.
The most important issue on OpenShift is that the runner uses a service account that has the rights to start containers in its namespace. It also needs a imagepull secret to be able to pull images from a registry. A runner on OpenShift must run its containers in the correct namespace and not through DockerInDocker (default).
This is done by applying the following to the config.toml of the runner on OpenShift: 

  config.toml: |
    [[runners]]
      name = "<runner-name>"
      url = "<gitlab-url>"
      clone_url = "<alternate-gitlab-url>"
      executor = "kubernetes"
      [runners.kubernetes]
        service_account = "gitlab-service-account"
        image_pull_secrets = ['gitlab-pull-secret']
        pull_policy = "if-not-present"
      [runners.kubernetes.pod_labels]
        "openshift.io/build.name" = ""

The configuration above ensures that the runner knows its running on OpenShift and needs to behave in that manner. It will use the OpenShift API to run containers with pipelines and wil not try to start them in the default way, which will result in failure.

.GitLab-ci-yaml

Tasks to be executed in a pipeline are specified in a file called ".gitlab-ci.yml".
In this file are the conditions when and how to run the code in that pipeline on any momment in the development process.
A pipeline is triggered on ANY update to the registry. Depending on the contents of the .gitlab-ci.yml, code will be executed, or not.

An example:

# Defaults
image: image-registry:5000/rh-python-image:latest

# List of pipeline stages
stages:
  - Verify ansible code

Verify_ansible_code:
  stage: Verify ansible code
  script:
    - ansible-lint

In the above example the pipeline is triggered on any update of the repository, there is no filtering done in this pipeline, so it will run on every update.
Every time this project is updated, a container is created by the gitlab runner and the ansible-lint is run for the project.

We see that the image for the container (rh-python-image) to run is pulled from a local registry. This image is a minimal redhat image with python installed and the ansible lint package. So it is not the runner container itself that runs your pipeline!

A .gitlab-ci.yml is yaml formatted, so multiple commands can be added to the list under 'script:'.

There are near to endless possibilities to what one can do using pipelines, in the end the list under the 'script' key is executed in a bash shell and everything you can do in bash, can be added to the list here.

Multiple stages can be defined with different conditions, read the documentation on the website of gitlab.com.
Much is also explained in the configuration as code explanation on this site.

Back

Backto Site