Git setzt sich zunehmend als eine Art Standard zur Versionsverwaltung bei Softwareentwicklern durch. Spätestens bei komplexeren Projekten wird Kontinuierliche Integration (CI) unverzichtbar, um die Qualität der Software zu gewährleisten sowie Abläufe effizient und einheitlich zu gestalten. Dank hoher Kompabilität und Flexibilität hat sich in diesem Bereich Jenkins einen Namen gemacht. Setzt man Jenkins zusammen mit Git ein erscheint schnell der Wunsch, einen Jenkins-Buildjob automatisiert durch einen Git-Commit ausführen zu lassen. GitLab bietet dafür bereits eine integrierte Lösung, leider jedoch nur in der kostenpflichtigen Enterprise-Edition. Deren Kauf lohnt sich alleine wegen einer rudimentären Jenkins-Verbindung aber nicht unbedingt, vor allem für Private oder sehr kleine Firmen.
Im folgenden Artikel zeigen wir, wie sich Jenkins dennoch rudimentär über GitLab steuern lässt – Ohne auf ineffizientes Polling zurückzugreifen.
Jenkins-Schnittstelle vorbereiten
Da wir ereignisorientiert arbeiten wollen, benötigt GitLab eine Schnittstelle von Jenkins, um den Buildjob zu starten. Jenkins bietet von Haus aus zwar bereits eine API an. Leider unterstützt diese nur HTTP-POST Anfragen, wogegen GitLab nur mit HTTP GET arbeitet. Daher benötigen wir das SCM API Plugin, um dies nachzurüsten. In dieser Konstellation sollte dies in der Regel aber bereits installiert sein – es ist nämlich eine Abhängigkeit des Git-Plugins.
Schlussendlich ist es noch notwendig, dies unter Angabe eines Sicherheitsschlüssels für das jeweilige Jenkins-Projekt zu aktivieren. Dazu öffnet man den gewünschten Buildjob per Mausklick und klickt auf Konfigurieren. Im Bereich Auslöser die Checkbox Builds von außerhalb startenb aktivieren und ein frei wählbares Authentifizierungstoken eintragen. Dies schützt Jenkins vor der Ausführung des Jobs via API durch unbefugte Dritte.
Als Basis-URL wird die URL des Jobs genutzt, wie in diesem Abschnitt bereits zu sehen. Für einen Job namens Test lautet diese somit http://jenkins-host.domain/job/Test. Je nachdem ob der Build parameterisiert ist oder nicht, hängen wir build (keine Parameter) oder buildWithParameters getrennt von einem Schrägstrich an. Schlussendlich benötigen wir in jeden Fall den GET-Parameter token mit dem festgelegten Authentifizierungstoken. Im Beispiel des Test-Projektes sehen die URLs somit wie folgt aus:
http://jenkins-host.domain/job/Test/build?token=Test123456
http://jenkins-host.domain/job/Test/buildWithParameters?token=Test123456¶m1=value1
API aus GitLab-Hook heraus aufrufen
Nun öffnen wir das dazugehörige GitLab-Projekt und klicken links unten in der Navigation auf Settings sowie anschließend Webhooks. In das URL-Feld wird die soeben ermittelte Jenkins-URL eingefügt. Als Trigger sollte nur Push events aktiviert sein:
Nach einem Klick auf Add Webhook sollte er in der Auflistung am Ende der Seite erscheinen. Dort kann man durch einen Klick auf Test Hook die URL testweise aufrufen lassen um sicherzustellen, dass alles wie gewünscht funktioniert:
Wurde alles richtig eingerichtet, sollte Jenkins nun mit der Ausführung des jeweiligen Jobs beginnen:
Sollte dies nicht klappen, empfiehlt es sich, die URL des Hooks wie sie in GitLab hinterlegt wurde einfach in einem normalen Internetbrowser zu öffnen. Jenkins gibt dann in der Regel eine Fehlermeldung aus, die zumindest Anhaltspunkte gibt, wo die Ursache zu suchen ist.
[box type=“info“ ]Die hier gezeigte Lösung weist leider gegenüber des GitLab-Plugins aus der Enterprise-Edition einige Einschränkungen auf. Beispielsweise lässt sich ohne weiteres kein spezieller Branch konfigurieren, auf den die Ausführung eingeschränkt werden soll. Dies lässt sich mit etwas mehr Aufwand über das GitLab-Plugin nachrüsten. Für einfache Anwendungsfälle dürfte die hier genannte Lösung jedoch ausreichen und daher eine sinnvolle Alternative gegenüber dem Kauf der Enterprise-Version darstellen. [/box]