Login
Newsletter
Werbung

Do, 17. Dezember 2015, 15:00

GitLab Continuous Integration

Vorbereitungen

Um GitLab CI zu verwenden, muss GitLab in der Version 8.0 oder höher installiert sein. Das Feature wird projektweise aktiviert und konfiguriert. Für die Steuerung der einzelnen Prozesse wird eine simple YAML-Datei mit dem Namen .gitlab-ci.yml im Hauptordner des Projekts erstellt - dazu gleich mehr.

CI Runner-Konfiguration

Christian Stankowic

CI Runner-Konfiguration

Projekt-Einstellungen

Um CI für ein GitLab-Projekt zu aktivieren, genügen die folgenden Schritte:

  1. Auswahl des Projekts, Anklicken von Settings und Project Settings.
  2. Anklicken von Builds und Save Changes.
  3. Auswahl von CI Settings, um erweiterte Parameter zu setzen. Dazu zählen u.a. Timeouts und automatische Builds.
  4. Anklicken von Save Changes.
  5. Auswahl von Runners, Notieren/Kopieren der CI-URL und des CI-Tokens - diese Informationen werden später benötigt, um die Runner zu registrieren.

Zur Steuerung der einzelnen Schritte auf dem Runner muss die YAML-Konfiguration erstellt werden. In dieser werden einzelne Teilschritte, Skripte und eventuelle Abhängigkeiten zu Runnern anhand Tags definiert.

Ein einfaches Beispiel sieht wie folgt aus:

before_script:
  - hostname

build:
  script:
    - "javac *.java"

clean:
  script:
    - "find . -type f -name '*.tmp' -exec rm {} \;"

In diesem Beispiel werden zwei Jobs definiert:

  • build - Skript zur Kompilierung aller Java-Quellcodes im aktuellen Verzeichnis
  • clean - Entfernen aller Dateien, die mit .tmp enden

Vor dem Ausführen der Jobs wird das hostname-Kommando ausgeführt. Der Job wird auf einem System aus dem Pool für das Projekt verfügbarer Runner ausgeführt. Durch die Verwendung von Tags kann man dieses Verhalten weiter einschränken:

before_script:
  - hostname

build_stable_jars:
  script:
    - "javac *.java"
  tags:
    - java
  only:
    - master

build_hipster_swag:
  script:
    - "bundle exec swag"

In diesem Beispiel gibt es erneut zwei Jobs:

  • build_stable_jars - Übersetzen von Java-Quellcodes aus dem master-Branch des Repositories; wird lediglich auf Runnern mit dem java-Tag ausgeführt
  • build_hipster_swag - Paketieren von Ruby-Anwendungen; kann auf allen Runnern ausgeführt werden und beschränkt sich auf keine Branch

Auf der GitLab-Webseite gibt es weitere Beispiele.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung