GitLab Webhooks

Vor ein paar Versionen, ich glaube es war mit Version 5.2, hat man bei GitLab Webhooks eingeführt. Damit konnte ich zunächst wenig anfangen, das hat sich aber inzwischen geändert

Ich bin ein großer Fan von GitLab (auch wenn die Updateprozeduren der Horror sind) und benutze es für alle Aufträge und Projekte an denen ich arbeite. Ich finde GitLab ist eine sehr gute Alternative zu GitHub.

Damit auch alles immer schön geschmeidig läuft und ich nicht mit jedem Push noch von Hand Dateien kopieren oder pullen muss, damit die Änderungen auf den Webseiten sichtbar sind, benutze ich Hooks.

Hooks?

Hooks sind kleine Scripte, die zu bestimmten Zeitpunkten ausgeführt werden, z.b. wenn etwas in ein Repository gepusht wurde. Man kann diese Hooks dazu nutzen, um Webseiten mit jedem Push automatisch zu aktualisieren, oder um mit jedem Commit ein dämliches Foto von sich zu schießen.

WebHooks?

Nun gibt es also diese Webhooks. Das Prinzip ist das gleiche. Mit jedem Push wird ein Script ausgeführt. Bisher waren diese Scripte bei mir einfache BaSh-Scripte. Die Webhooks allerdings funktionieren ein bisschen anders. Anstatt im Repository ein entsprechendes Script anzulegen, kann man nun in GitLab selber die URL zu einem Webhook angeben.
Mit jedem Push wird diese URL aufgerufen und die relevanten Daten des Pushes als JSON-String übergeben.

Das hat den Vorteil, dass man mehrere Script ausführen lassen kann, indem man einfach mehrere URLs hinzufügt.
Das hat den Nachteil, dass man nicht mehr ohne Weiteres einfach ein BaSh-Script basteln kann, weil diese nicht über eine URL erreichbar sind.

Die Lösung

Ich habe mich also umgesehen und nach einiger Zeit ein passendes PHP-Script gefunden, welches mir zusagte.
Das Script wertet den übergebenen JSON-String aus und aktualisiert dann entsprechende Branches und legt sogar neue Branches an, sollten diese noch nicht existieren.

Habe ich also etwas in den master-branch gepusht wird die URL (das PHP-Script) aufgerufen. Existiert noch kein Abbild des Branches, wird ein Verzeichnis "master" angelegt und ein Clone erstellt. Existriert das Verzeichnis schon, wird es aktualisiert.

So weit so gut.

Zwei Dinge passten mir nicht so gut.

1. Ich muss bei jedem neuen Repository das Script kopieren und den dort drin fest definierten Pfad und die URL zum Repository anpassen.
2. Es kann sehr gut sein, dass ich an Branches arbeite, die auf dem Server auf dem die Seite liegt überhaupt nicht auftauchen müssen. Gerade bei größeren Projekten schwirren durchaus mal mehrere Branches rum, die dann irgendwann gemerged werden, aber nirgendwo anders abgebildet werden sollen.

Die angepasste Lösung

Ich habe mir also das Script genommen und mir überlegt, wie man das besser gestalten kann. Und so sieht meine Lösung aus:

Das PHP-Script wird auf dem Server abgelegt, auf dem auch die Webseiten liegen. Ich habe mir dazu einen vhost angelegt, damit ich eine nette Domain dafür habe. Das Script muss nur einmal existieren.

Außerdem habe ich eine config-Datei erstellt. Eine einfache JSON-Datei die wie folgt aufgebaut ist:

{
    "repoName": {
        "path": "/path/to/folder",
        "limit": null
    }
}

Der Name des Repositories muss dem Namen in GitLab entsprechen, dieser wird im GitLab-JSON übergeben und darüber die Referenz in die Config hergestellt.

path ist das Verzeichnis in dem die Unterverzeichnisse für die Branches angelegt werden sollen. In den meisten Fällen dürfte das irgendwo im Document-Root der entsprechenden Seite liegen.

limit kann null sein, dann werden alle Branches angelegt und aktualisiert. Will man, dass nur bestimmte Branches verwaltet werden, kann man diese Branches hier Komma separiert eintragen.

"limit": "master,testing"

Das wiederholt man für jedes Repository.
Auf diese Weise muss man nur zwei Dateien pflegen. Die PHP-Datei und die config-Datei. Passt man das PHP-Script an, muss man das nur an einer Stelle und nicht mehrfach tun.

Probleme?

Damit das Script läuft, müssen noch ein paar grundlegende Schritte erledigt werden (Deploy-Key anlegen etc.), die ich hier aber nicht erklären möchte, weil das im Blogpost zum originial Script schon ausführlich getan wird.

Hinweis meridimus war so nett in den Kommentaren darauf hinzuweisen, dass bei Schritt 7 des Original-Artikels das Verzeichnis ebenfalls Ausführrechte braucht, damit die known_hosts Datei angelegt werden kann:

$ sudo chmod -R 0600 /var/www/.ssh
$ sudo chmod 0700 /var/www/.ssh
$ sudo chown -R www-data:www-data /var/www/.ssh

Download

Wer Interesse an meinem Deploy-Script hat, kann es sich auf GitHub ansehen.

Update

Ich habe noch einen Artikel darüber geschrieben, wie Sie mit einem einfachen Bash-Script die Deploy-Konfiguration automatisieren können.