Adding Gitlab-CI support

Setup of Gitlab builder

Following our post about how to setup Gitlab with Nginx and Let’s Encrypt, we continue with our infrastructure setup by adding a Gitlab Runner. This allows us to add automated builds from repositories, build checks and testing before merge requests are acceptable,…

First, setup of the gitlab-runner repo on ubuntu

# Install the gitlab runner ubuntu repository
$ curl -L | sudo bash

Next we install the gitlab-runner package

$ apt update
$ apt install gitlab-runner

Once the package has been installed we can go to our gitlab page. Navigate to the repository of which we want to setup a runner and go to the settings page of the repository.

Once at the settings page there a pane called pipelines. At this page we find 2 important pieces of information needed to setup our gitlab runner. The URL and the registration token used to link the runner to our gitlab instance.

With this info we go back to our gitlab-runner. Now we will register our runner.m

$ gitlab-runner register

Just follow the steps provided on the screen, entering the url, token and as executor we use “shell”. We are not using docker of parallels at this moment. So we can just run on the native machine.

Once configured we can run:

$ gitlab-runner --debug run

In order to monitor the progress of the runner and validate it’s working. Later we can remove the “–debug”.

Now the only thing left to do is add a .gitlab-ci.yml file to the git repo that has to be automatically build. For example:

# This file is a template, and might need editing before it works on your project.
# use the official gcc image, based on debian
# can use verions as well, like gcc:5.2
# see
# Only used when we are running on a docker slave
image: gcc

    stage: build
    # instead of calling g++ directly you can also use some build toolkit like make
    # install the necessary build tools when needed
        - pip3 install --user meson
        - meson build
        - cd build
        - ninja
            - build/demo
                      # depending on your build setup it's most likely a good idea to cache outputs to reduce the build time
            - "*.o"
# run tests using the binary built before
# test:
#  stage: test
#  script:
#    - ./