Kontinuierliche Integration, auf Englisch Continous Integration (kurz CI) ist in der professionellen Softwareentwicklung längst zum elementaren Standard geworden. Das Bauen der Software muss kein lästiger Arbeitsschritt sein, sondern lässt sich bequem in den Arbeitsablauf integrieren: Beispielsweise löst das Pushen in einen bestimmten Branch wie dev das Erstellen auf einem Entwicklersystem auf. Wogegen ein Merge-Request als Trigger für das Ausrollen aufs Produktivsystem genommen wird.
Im Artikel GitLab-Push als Trigger für Jenkins mit GitLab Community ohne Enterprise haben wir bereits gezeigt, wie sich dies auch mit der kostenfreien Community-Edition dank des SCM API-Plugins realisieren lässt. Seit GitLab 8.3 gibt es eine offizielle Lösung, die mit beiden Editionen funktioniert: Das von Jenkins bereitgestellte GitLab-Plugin. Es simuliert einen GitLab-CI Server, sodass sämtliche GitLab-Hooks genutzt werden können, um ein Projekt zu bauen.
Jenkins-Einrichtung
Zunächst installieren wir das genannte GitLab Plugin in Jenkins. In der Konfiguration der Jobs findet sich im Register Source-Code-Management am Ende der Abschnitt Build-Auslöser. Das Plugi hat hier einen zusätzlichen Eintrag Build when a change is published to GitLab eingefügt:
Dieser Haken muss gesetzt sein. Wichtig ist außerdem die am Ende erwähnte URL. Sie wird am besten Kopiert, da wir diese im nächsten Schritt als Ziel des GitLab-Hooks benötigen. Im unteren Bereich lässt sich darüber hinaus noch festlegen, welche Events grundsätzlich einen zulässigen Trigger darstellen, und wie jeweils reagiert werden soll. Wobei dies nur die Jenkins-Seite darstellt.
Konfiguration der GitLab-Hooks
Im dazugehörigen GitLab-Projekt Klicken wir oben auf den Reiter Settings sowie in der sich öffnenden Sub-Navigation auf Integrations. Als URL fügen wir die soeben aus Jenkins kopierte Adresse für den Job ein, die Jenkins aufrufen wird.
Im unteren Bereich lassen sich verschiedene Ereignisse auswählen. Push-Events und Merge-Requests sind hier wohl am interessantesten. Natürlich lassen sich diese Events auch außerhalb von Jenkins nutzen, um beispielsweise eigene Benachrichtigungen in verschiedenen Kanälen zu erzeugen. Hat man den oder die gewünschten Ereignisse ausgewählt, wird der Hook mit Add Webhook abgespeichert.
Darunter ist eine Auflistung aller aktiven Hooks zu sehen:
Über den Test Button lässt sich die korrekte Funktion prüfen. Klappt alles, sollte Jenkins den Job starten und diesen mit dem GitLab-Nutzernamen versehen, der das jeweilige Event – in diesem Beispiel einen Merge-Request – ausgelöst hat:
Verwendete Software für diesen Artikel:
GitLab 9.0.5
Jenkins 2.40