Jenkins master – Zu wenig Speicherplatz

Mit der Zeit kann es vorkommen, dass der frei verfügbare Speicherplatz auf dem Server auf dem Jenkins läuft, immer kleiner wird. Das kann unter Anderem auch an Jenkins selbst liegen.

In diesem Post möchte ich ein paar Hilfestellungen geben, wie man dieses Problem lösen und auch vorbeugen kann. Ich werde in diesem Post von meiner Jenkins Installation ausgehen, die auf einem Ubuntu-Server installiert ist. Auf anderen Linux- oder Windows-Servern muss man die vorgestellten Strategien jedoch anpassen.

Speicherhungrige Jobs finden

Auf meinem Ubuntu-Server ist Jenkins unter dem Pfad /var/lib/jenkins installiert. Unter diesem Ordner gibt es einen Ordner namens jobs, in dem es wiederum weitere Ordner gibt. Jeder dieser Ordner ist nach dem jeweiligen Job in Jenkins benannt. Wenn man also einen Job namens First Job hat, dann findet man unter jobs einen Ordner, der auch First Job heißt.

Mit dem Kommandos

cd /var/lib/jenkins/jobs

du -h –max-depth=1 | sort -hr

bekommt man nun eine Auflistung aller Ordner in jobs und die Größe aller Dateien zusammen vom jeweiligen Ordner.

Auf diese Weise kann man erkennen, welche Jobs den meisten Speicherplatz belegen. In meinem Fall ist das jedoch noch kein Problem. Will man jedoch für mehr Speicherplatz sorgen gib, kann es helfen, die Anzahl der Builds zu limitieren.

Anzahl der Builds limitieren

Standardmäßig speichert Jenkins jeden Build ab, den ein Job je ausgeführt hat. Insbesondere auch dann, wenn man anfängt, Artefakte zu archivieren (eine Post-build Aktion), kann der verfügbare Speicherplatz je nach Projekt sehr schnell klein werden. Wenn man aber die Anzahl der Builds limitiert, werden alte Builds von Jenkins automatisch gelöscht und es wird regelmäßig Speicherplatz wieder frei gelegt.

Um die Anzahl der Builds zu limitieren, muss man in einer Job-Konfiguration unter General einen Haken vor Discard old builds setzen und je nach belieben Werte einsetzen:

Anschließend das Speichern nicht vergessen 😉

Ein Jenkins Plugin installieren

Erst durch die vielen Plugins wird Jenkins zu dem was es ist: Ein sehr mächtiges Werkzeug. Doch wie installiert man ein Plugin in Jenkins? In diesem Post will ich aufzeigen, wie man in Jenkins Plugins installieren kann.

Manage Plugins

Der übliche Weg geht über den Link Manage Jenkins.

Wenn man auf den Link Manage Jenkins klickt, taucht eine neue Seite mit einer Reihe von Buttons. Einer davon hat den Titel Manage Plugins.

Wenn man auf diesen Knopf drückt, kommt man auf die Seite, auf der man Plugin installieren kann.

Auf dieser Seite muss man in den Reiter Available wechseln. Dort wird eine Reihe von installierbaren Plugins aufgelistet. Jetzt muss man dort nach dem gewünschten Plugin suchen. Dabei kann man das Suchfeld rechts oben zur Hilfe nehmen.

Hat man das gewünschte Plugin gefunden, setzt man einen Haken links neben dem Namen des Plugins. In meinem Beispiel will ich jetzt das Plugin Pipeline installieren.

Im Browser unten müsste sich jetzt ein Knopf namens Download now and install after restart befinden. Diesen muss man drücken. Anschließend startet man Jenkins neu.

 

Jobs triggern Jobs in Jenkins – Parameterized Plugin

Neben den Boardmitteln von Jenkins, weitere Jobs zu triggern, gibt es einige Plugins, die dasselbe erledigen und dabei mehr Einstellungen anbieten können. In diesem Post geht es um das Plugin namens Parameterized Plugin. Dieses Plugin erlaubt es, in einem Job oder am Ende eines Jobs weitere Jobs zu starten und dazu noch Parameter zu übergeben. Ich nehme jetzt an, dass der Leser/die Leserin das Plugin Parameterized Plugin schon installiert hat.

Job vor Job starten

Es gibt Fälle, da möchte man einen Job laufen lassen, bevor der eigentliche Job gestartet wird. Mit dem Parameterized Plugin  geht das folgendermaßen: In der Konfiguration des eigentlichen Jobs geht man in die Build-Sektion und fügt dort einen neuen Build-Schritt hinzu: Trigger/call builds on other projects.

Nun müsste ein neuer Build-Schritt erscheinen. Diesen muss man eventuell nach oben schieben, je nachdem, wie man es haben möchte und entsprechend konfigurieren (siehe nächstes Bild). Second Job ist in dem Fall ein zweiter Job, den ich in diesem Beispiel starten möchte, bevor der eigentliche Build-Prozess von dem aktuellen Job gestartet wird.

Nun kann man weiter unten auf Save drücken und es einfach mal ausprobieren. Dabei muss man darauf achten, dass die entsprechenden Knoten (master / slaves) genügend Slots haben. Ansonsten könnte es passieren, dass ein Job einen anderen blockiert.

Job nach Job starten

Genauso wie man einen Job vor einem Job starten kann (siehe das Unterkapitel weiter oben), kann man auch einen Job nach einem anderen Job starten. In diesem Fall fügt man in der Liste der Post-build-Aktionen eine weitere Aktion hinzu: Trigger parameterized build on other projects.

Nun müsste ein neuer Bereich in den Post-build-Aktionen aufgetaucht sein. Diesen gilt es nun anzupassen und dann mit einem Klick auf Save zu speichern.

Jobs triggern Jobs in Jenkins

In diesem Post möchte ich euch zeigen, wie man einen zweiten Job startet, wenn der erste fertig ist. Das lässt sich mit den Boardmitteln von Jenkins recht einfach realisieren. Dazu muss man in den Post-build actions den Punkt Build other projects auswählen und dann den Namen des anderen Jobs eintragen.

In diesem Fall habe ich zu Testzwecken einen zweiten Job namens Second Job erstellt, der gestartet wird, wenn der erste erfolgreich fertig geworden ist.

Wie man in dem obigen Bild sieht, kann man einstellen, wann der zweite Job Second Job gestartet werden soll. Dies kann geschehen, wenn der erste Job erfolgreich war (Trigger only if build is stable), oder wenn das Ergebnis vom ersten Job instabil ist (Trigger even if the build is unstable) oder auch dann, wenn der erste Job fehlgeschlagen ist (Trigger even if the build fails). Ich habe das jetzt einfach mal auf Trigger only if build is stable eingestellt.

Ist alles eingerichtet, sieht man das auch später in der Liste der Downstream Projects:

Nun kann man einen Testlauf durchführen und den ersten Job starten. Nach dem Ende des ersten Jobs sollte automatisch der zweite gestartet werden (je nachdem, wie das Ergebnis des ersten Jobs ist und welche Einstellung man gewählt hat).