Gitlab stellt auch in der kostenfreien Community Variante einen CI (Continuous Integration) Mechanismus zur Verfügung, mit dem Tests gebaut werden können.

Mein Anwendungszweck ist hierbei der Syntax-Check für Ansible Playbook welches sich in meinem Gitlab-Repo befindet und bei jedem neuen Commit automatisch kontrolliert wird.
Der Vorteil ist hierbei auch, dass man z.B. einen Merge in den Master-Branch von einem erfolgreichem durchlaufen des entsprechenden Tests abhängig machen kann.

gitlab-runner

gitlab-runner ist eine in Go geschriebene Binary, welche sich um die CI kümmert.

Die verschiedenen Möglichkeiten für eine Installation findet man hier: docs.gitlab.com

Hierbei kann man den gitlab-runner als Systemdienst oder auch in einem docker-Container installieren und starten.

Installation in einem docker-Container:

• Installation docker:
  curl -sSL https://get.docker.com/ | sh

• starten des docker-Containers

docker run -d --name gitlab-runner --restart always \
   -v /srv/gitlab-runner/config:/etc/gitlab-runner \
   -v /var/run/docker.sock:/var/run/docker.sock \
   gitlab/gitlab-runner:latest

Im Anschluß sollte ein entsprechender Container laufen.

$ docker ps
CONTAINER ID        IMAGE                         COMMAND                  CREATED             STATUS              PORTS               NAMES
3a3c277df132        gitlab/gitlab-runner:latest   "/usr/bin/dumb-init …"   About an hour ago   Up About an hour                        gitlab-runner

Nun aktiviert man im entsprechenden Repo die Auto-Dev-Ops Funktion.

Einen dedizierten gitlab-runner für ein Repo verwenden

In Gitlab wechselt man in das entsprechende Repo und klickt im Menü auf der linken Seite auf Einstellungen —> CI/CD.

Dort kann man sich zunächst die allgemeinen Einstellungen anschauen und entscheiden ob man lieber ein git clone oder git fetch machen möchte.

Darunter gelangt man zu den Auto-Dev-Ops Einstellungen.
Hier kann man z.B. angeben wie die Bereitstellungsstrategie sein soll.

Im Abschnitt darunter finden sich die Einstellungen für die gitlab-runner.
Hier findet sich der Registrierungs-token, welcher benötigt wird um einen gitlab-runner für das Repo zu aktivieren.

Um einen gitlab-runner extra für dieses Projekt zu aktivieren: Dazu führt man im Terminal den folgenden Befehl aus: gitlab-runner register und trägt die entsprechenden Infos ein. Hierbei als erstes die Domain unter der die gitlab-Instanz zu finden ist. Anschließend benötigt man den registrierungs-token. Nun trägt man noch eine kurze Beschreibung des gitlab-runners ein und mit welchen tags der runner angesprochen wird. Abschließend gibt man die Art an, wie bzw. auf welcher Plattform der Test durchgeführt werden soll. Zur Auswahl stehen aktuell:

• ssh
• docker+machine
• docker-ssh+machine
• kubernetes
• docker
• parallels
• virtualbox
• docker-ssh

Weitere Einzelheiten finden sich in der Dokumentation: docs.gitlab.com

Nun sollte sich auf der Seite mit den CI/CD-Einstellungen im Bereich Runners eine Auflistug der entsprechenden gitlab-runner befinden:

Hier können die gitlab-runner auch gestoppt oder entfernt werden.

Man kann Runners aber auch im Admin-Bereich unter Übersicht —> Runners einzelnen Repos zuweisen, indem man bei dem betreffenden Runner auf bearbeiten (Stift-Icon) klickt und unter Restrict projects for this Runner die gewünschten Repos/Projekte hinzufügt.

Einen Test bauen

Tests bzw. die einzelnen Schritte werden in der .gitlab-ci.yml definiert, welche im Repo angelegt werden muss.

Hierbei können diverse Schritte, mit Vorbedingungen, Stages, Variablen, script-befehlen, etc.. eingetragen werden.

Eine Übersicht findet sich hier: docs.gitlab.com

Meine .gitlab-ci.yml Datei sieht wie folgt aus:

stages:
  - syntax_check
build:
  stage: syntax_check
  script: 
    - source /home/gitlab-runner/ansible/hacking/env-setup 1> /dev/null
    - ansible --version
    - ansible-playbook playbook.yml -i hosts --syntax-check

Hierbei gebe ich an, dass mein Test nur eine Stage besitzt und diese heisst syntax_check.
Anschließend folgt der Job build den man nennen kann wie man möchte.
Hier wird festgelegt das die Stage syntax_check ausgeführt wird, welche sic durch die Abfolge der nachfolgenden script-Schritte definiert.
Bei den Schritten unterhalb von script springe ich in das VirtualEnv der aktuellen Ansible-Developer-Version, lasse mir zur Überprüfung die Ansible-Version anzeigen und starte anschließend den Syntax-Check.
Gibt dieser ganze Ablauf den Exit-Code 0 zurück gilt der Test als erfolgreich abgeschloßen.

Der Status des jeweils letzten Tests wird auf der Übersichtsseite des Repos durch Symbole angezeigt. grünes Häckchen Erfolg; rotes Kreuz Fehlgeschlagen.

Ein Log eines Test sieht dann wie folgt aus:

Des weiteren sollte dieser Test jedes mal automatisch durchlaufen werden, wenn ein push auf das Repo erfolgt.