GitLab CI ist die in GitLab eingebaute Pipeline, beschrieben in einer Datei im Repository. Ein Push löst sie aus, und die Stufen darin laufen auf Maschinen, die GitLab Runner heißen.
- GitLab CI
Die in GitLab eingebaute Pipeline, beschrieben in einer Datei im Repository.
Beispiel: „GitLab CI prüfte bei jedem Push den Stil, die Typen und die Tests, bevor jemand den Merge Request ansah.“Die Datei heißt .gitlab-ci.yml und liegt im Wurzelverzeichnis. Darin stehen Stufen und Aufgaben, dazu Bedingungen, wann eine Aufgabe überhaupt läuft.
Abgrenzung zu GitHub Actions: Dieselbe Aufgabe bei der anderen Plattform. GitLab bringt die Pipeline seit jeher mit, GitHub hat sie 2019 nachgerüstet.
Wie eine Pipeline in GitLab CI aufgebaut ist
In Stufen und Aufgaben. Die Stufen laufen nacheinander, die Aufgaben einer Stufe gleichzeitig; jede Aufgabe nennt ein Abbild, in dem sie läuft, und die Befehle, die sie ausführt.
Zwischen den Stufen wandern Ergebnisse als Artefakte weiter, und Zwischenspeicher halten Abhängigkeiten über Läufe hinweg. Beides zusammen entscheidet darüber, ob ein Lauf zwei oder zwölf Minuten braucht.
Was ein Runner ist
Die Maschine, die die Aufgaben ausführt. GitLab stellt geteilte Runner bereit und rechnet die Minuten ab; wer eigene aufstellt, zahlt dafür nichts an GitLab und bekommt Zugriff auf das eigene Netz.
Eigene Runner sind auch der Weg, ein Deployment aus der Pipeline heraus zu starten, ohne den Zielserver von außen erreichbar zu machen.
Wann GitLab CI passt
Wenn der Code ohnehin in GitLab liegt. Dann ist die Pipeline eine Datei weit entfernt, die Rechte sind geregelt, und die Ergebnisse stehen am Merge Request, wo sie gebraucht werden.
Für Projekte auf GitHub lohnt der Umweg nicht, und wer gar keine Plattform hat, steht vor der Frage nach einem eigenen Server, siehe Jenkins.