Seite wählen

Continuous Integration with Golang and GitLab

von | Jun 7, 2018 | GitLab, Golang, Development

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
get:
        go get ./...
build:
        go build ./...
install:
        go install ./...
test:
        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
stages:
  - build
before_script:
  - apt-get update && apt-get install -y make curl
  - curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
  - mkdir -p /go/src/git.icinga.com/icingadb
  - ln -s /builds/icingadb/icingadb /go/src/git.icinga.com/icingadb/icingadb
  - cd /go/src/git.icinga.com/icingadb/icingadb
  - dep init && dep ensure
build:
  stage: build
  script:
    - 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:

^total:\t+\(statements\)\t+(\d+\.\d+)%

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 ?

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr Beiträge zum Thema GitLab | Golang | Development

Mein PHP-Trainingsprojekt

PHP Schulung Vor kurzem haben wir begonnen, eine neue Programmiersprache zu lernen – PHP. In der ersten Woche haben wir mit den Grundlagen wie Variablen, Arrays, Schleifen begonnen und uns schrittweise zu komplizierterer Syntax wie Funktionen, Objekten und Klassen...

check_prometheus ist jetzt öffentlich verfügbar!

Monitoring ist komplex, das wissen wir hier bei NETWAYS leider zu gut. Deswegen laufen in der Infrastruktur auch mal gerne mehrere Tools für die Überwachung. Zwei gern gesehene Kandidaten sind dabei Icinga und Prometheus. Icinga und Prometheus erfüllen...