Today you not only develop code and collaborate with other developers in your Git branches and forks. In addition continuous integration helps with “instant” compile and runtime tests. Which Git commit caused a failure, are there any performance changes with the recent code history?

Today I want to dive into our latest insights into Golang and building our code inside GitLab on each push and merge request. Golang extensively supports unit tests and also their analysis with coverage tests. This ensures that code isolated in test interfaces runs rock-solid and you can focus on the more important tasks and features.

In order to abstract the Go build and install calls, we add a Makefile for convenience. This also allows developers to manually use it, if they want.

$ vim Makefile

.PHONY: all test coverage

all: get build install

        go get ./...

        go build ./...

        go install ./...

        go test ./... -v -coverprofile .coverage.txt
        go tool cover -func .coverage.txt

coverage: test
        go tool cover -html=.coverage.txt

The “coverage” target runs the tests and stores the coverage results in “.coverage.txt”. This is then converted into HTML and can be opened with a browser for example.

Inside GitLab we need a CI runner configured for our project and job pipeline. This is already available in the NWS app. If you want to learn more about GitLab CI/CD, containers, jobs and pipelines, I’ll invite you to join me for the official GitLab training sessions 🙂

The CI configuration file is stored in “.gitlab-ci.yml” inside the Git repository and uses the Golang image for Debian Stretch in this example.

$ vim .gitlab-ci.yml

image: golang:1.10-stretch

  - build

  - apt-get update && apt-get install -y make curl
  - curl | sh
  - mkdir -p /go/src/
  - ln -s /builds/icingadb/icingadb /go/src/
  - cd /go/src/
  - dep init && dep ensure

  stage: build
    - make test

The “before_script” tasks can be moved into your own Docker image which can be made available in the GitLab container registry too. At some later point when dependencies are fixed, we’ll remove the “dep init” step and just use the locked versions from inside our Git repository.

The test coverage should also be highlighted in the job output. This can be extracted with a regular expression using the shell output from the tests. Nagivate into “Settings > CI/CD > General pipeline settings > Test coverage parsing” and add the following regex:


Each pushed branch and merge request will then automatically be built and also shows the test coverage. There’s room for improvement here, the next months will ensure to add more unit and runtime tests 😎

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉