Jenkins Workflow Skripting komplexer Builds

In diesem zweiten und letzten Teil der Serie werfen wir einen Blick auf das Workflow-Plugin von Jenkins als Lösung für die Einrichtung komplexerer Jenkins-Pipelines.

Wir werden da weitermachen, wo der erste Teil der Serie aufgehört hat. Im ersten Teil führte Sie Jeff Reifman durch die Einrichtung einer Jenkins-Instanz auf Digital Ocean und die Erstellung Ihres ersten Jenkins-Builds. Wenn Sie es noch nicht gelesen haben, empfehle ich es, bevor Sie fortfahren. Es ist okay, ich warte. Ich kann sehr geduldig sein…

… Alles aufgeholt? Großartig! Lass uns das machen.

Was ist Jenkins Workflow??

Jenkins Workflow ist ein Plugin für Jenkins. Nach der Installation wird ein neuer Artikeltyp verfügbar: ein „Workflow“. Workflow-Projekte können für dieselben Zwecke wie reguläre „Freestyle“ -Projekte von Jenkins verwendet werden. Sie können jedoch auch viel größere Aufgaben verwalten, die sich auf mehrere Projekte erstrecken, und sogar mehrere Arbeitsbereiche in einem einzigen Workflow erstellen und verwalten. Darüber hinaus kann dieses gesamte Management in einem einzigen Skript organisiert werden, anstatt sich auf eine Reihe von Konfigurationen, Projekten und Schritten zu verteilen.

Der Pre-Workflow

Bevor wir mit dem Erstellen von Workflows beginnen können, müssen Sie das Jenkins Workflow-Plugin installieren. Klicken Sie im Jenkins Dashboard auf Jenkins verwalten, dann Plugins verwalten. Wechseln Sie zu Verfügbar Registerkarte und Suche nach "Workflow".

Aktivieren Sie das Kontrollkästchen für Workflow-Plugin, dann Installation ohne Neustart.

Nun, hier ist der Haken. Es gibt mehrere Plugins mit dem Namen "Workflow Plugin", daher müssen Sie die obigen Schritte mehrmals wiederholen. Alternativ können Sie auch auf mehrere Kontrollkästchen klicken oder das Workflow Aggregator-Plugin installieren.

Wenn "Workflow Plugin" nicht mehr in der Liste der verfügbaren Plugins angezeigt wird, starten Sie Jenkins neu, indem Sie zu navigieren /Neustart und klicken Ja.

Ein einfacher Fluss

Lassen Sie uns unsere Workflow-Füße nass machen. Wir nehmen das Projekt, das Jeff im ersten Teil eingerichtet hat, als Workflow auf.

Beginnen Sie mit dem Jenkins Dashboard und klicken Sie auf Neuer Gegenstand. Benennen Sie den neuen Eintrag "Shell Test (Workflow)" und wählen Sie die Option Arbeitsablauf Art.

Klicken OK um das neue Projekt zu erstellen. Sie landen auf der Konfigurationsseite des Projekts.

Sie werden feststellen, dass sich die Konfigurationsoptionen von Standard-Jenkins-Projekten unterscheiden. Es gibt keine Optionen mehr zum Hinzufügen eines GitHub-Repos, zum Erstellen von Schritten oder für Aktionen nach dem Build. Stattdessen gibt es einen neuen Abschnitt Arbeitsablauf.

Innerhalb des Workflow-Abschnitts befindet sich ein Textfeld Skript. Hier definieren Sie das Workflow-Skript, das Jenkins ausführt, wenn ein Build des Projekts initialisiert wird.

„Welche Art von Skript?“, Fragen Sie. Ausgezeichnete Frage. Das Jenkins Workflow-Plugin verwendet für seine Skripts eine Sprache namens Groovy. Groovy ist eine vielseitige Skriptsprache für die JVM. Machen Sie sich keine Sorgen, Sie müssen nicht unbedingt Groovy oder Java kennen, um die Dinge zum Laufen zu bringen - das Jenkins Workflow-Plugin verwendet ein kleines DSL neben Groovy und es ist sehr einfach, Befehle zu kombinieren, um Ihren Projektworkflow zu verbessern.

Fahren Sie fort und fügen Sie der Skriptbox Folgendes hinzu:

Java-Knoten git 'https://github.com/redhotvengeance/hello-jenkins.git' sh 'uptime'

Was passiert also hier??

Zunächst öffnen wir eine Knoten Block. In Knoten werden Workflow-Aktionen ausgeführt. Bei der Zuweisung einer Knoten, Ein neuer Arbeitsbereich (ein Kontext / Ordner) wird erstellt. Der gesamte Code innerhalb der Knoten Block wird innerhalb dieses Arbeitsbereichs ausgeführt. Dadurch wird sichergestellt, dass sich die Build-Schritte nicht gegenseitig belasten.

Als Nächstes führen wir einen Git-Befehl mit aus git 'https://github.com/redhotvengeance/hello-jenkins.git'. Dieser Befehl kopiert das Git-Repo in unseren Arbeitsbereich.

Zum Schluss weisen wir Workflow an, das auszuführen Betriebszeit Shellbefehl mit sh 'Betriebszeit'.

Klicken sparen, und Sie werden zur Projekt-Landing-Page weitergeleitet. Im linken Menü befindet sich eine Schaltfläche Jetzt bauen. Klicken Sie darauf, um einen Build zu starten.

Sobald der Build abgeschlossen ist, klicken Sie auf Build # 1 gefunden in der Geschichte erstellen Sektion. Dann klick Konsolenausgabe im linken Menü.

Hier können wir alles protokollieren, während der Build ausgeführt wurde. Es begann mit der Zuweisung eines Knotens im Arbeitsbereich "Shell Test (Workflow)". Dann holte es das Git-Repo. Schließlich wurde das ausgeführt Betriebszeit Shell-Skript, das die Server-Betriebszeitstatistiken gedruckt hat.

Und das ist es! Wir haben jetzt die gleichen Schritte wie das normale Jenkins-Projekt-Setup in Teil 1 neu erstellt, außer als Workflow. Lasst uns jetzt dieselben Konzepte verwenden, um etwas komplexeres zu machen.

Fake it bis du es machst

Bevor wir unseren komplexen Workflow erstellen können, benötigen wir die Arbeit, die durch ihn fließt. Gefälschte Projekte zur Rettung!

Da wir bereits Groovy für das Scripting unseres Workflows verwenden, verwenden wir Gradle für unsere gefälschten Projekte. Gradle ist ein Build-System, das Groovy verwendet (überraschend, ich weiß!). Um Gradle verwenden zu können, müssen wir es auf unserem Server installieren. SSH auf Ihrem Server (überprüfen Sie Jeffs Teil 1, wenn Sie Ihr Gedächtnis auffrischen möchten) und führen Sie Folgendes aus:

Shell Sudo apt-get installieren Gradle

Da sind wir gut zu gehen.

Wir verwenden zwei Repos in unserem neuen Workflow. Der erste ist der Baumeister. Unser Builder-Projekt ist sehr einfach - es enthält ein Gradle-Build-Skript mit dem folgenden Code:

groovige Aufgabe createBuild << new File("built.txt").write("You cannot pass.\n")

Was ist also hier los? Gradle führt die Ausführung von "Aufgaben" aus und das Gradle-Build-Skript definiert diese Aufgaben. Wir haben eine aufgerufene Aufgabe definiert createBuild, und es wird eine Textdatei mit dem Namen erstellt built.txt mit dem Inhalt:

Sie können nicht durchgehen.

Das ist es. (Nun, ich tat sag es war einfach!)

Das zweite Git-Repo ist unser Packager. Der Packager verfügt auch über ein Gradle-Build-Skript, das jedoch etwas komplexer ist:

groovy Aufgabe createPackage << String packageText = "I am a servant of the Secret Fire, wielder of the flame of Anor. You cannot pass. The dark fire will not avail you, flame of Udûn. Go back to the Shadow!" String builtText = new File('built.txt').text new File("package.txt").write(packageText + "\n\n" + builtText)

Das createPackage Aufgabe erstellt auch eine Textdatei (genannt package.txt), erwartet jedoch die Verwendung von Inhalten aus built.txt, was im Packager Repo nicht vorhanden ist. Ob built.txt Im Repo existierte das generierte package.txt würde enthalten:

Ich bin ein Diener des geheimen Feuers, Träger der Flamme von Anor. Sie können nicht durchgehen. Das dunkle Feuer wird dir nichts nützen, Flamme von Udûn. Gehe zurück zum Schatten!

Sie können nicht durchgehen.

Ob built.txt fehlt, unser createPackage Task wirft einen Fehler.

Jedes Mal, wenn wir unseren Paketierer erstellen, müssen wir zuerst unseren Builder ausführen und das Ergebnis erstellen built.txt für den Packager verfügbar, damit er erstellt werden kann package.txt.

Und genau das wird ein Jenkins Workflow sein!

Lassen Sie die Arbeit durch Sie fließen

Gehen Sie zum Jenkins Dashboard, klicken Sie auf Neuer Gegenstand, Nennen Sie es „Assembler“, wählen Sie Arbeitsablauf, und klicken Sie auf OK.

Beginnen wir mit dem Scripting. Zuerst öffnen wir eine Knoten Block wie zuvor:

"Java-Knoten

Als nächstes klonen wir unser Builder-Repo:

Java-Knoten git 'https://github.com/redhotvengeance/jenkins-workflow-build.git'

Jetzt müssen wir unser Gradle-Build-Skript ausführen, um das zu generieren built.txt Datei:

Java-Knoten git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild'

Schließlich stellen wir sicher, dass alles so funktioniert, wie wir es erwarten. Wir werden ein hinzufügen Katze um den Inhalt der zu drucken built.txt Datei:

Java-Knoten git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild' sh 'cat ./built.txt'

Klicken sparen, und starten Sie dann einen Build. Wenn es fertig ist, werfen Sie einen Blick auf die Konsolenausgabe.

Ausgezeichnet! Wir klonen erfolgreich das Repo und führen das createBuild Aufgabe und haben bestätigt, dass der Inhalt von built.txt ist Sie können nicht durchgehen.. Nun zum Packager.

Genau wie beim Builder müssen wir unser Packager-Repo klonen. Fügen wir den Packager-Code hinzu:

"Java-Knoten git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild' sh 'cat ./built.txt'

node git 'https://github.com/redhotvengeance/jenkins-workflow-package.git' sh 'gradle createPackage' sh 'cat ./package.txt' "

Da wir nicht explizit einen neuen Arbeitsbereich erstellt haben, wird der createPackage Task wird in demselben Arbeitsbereich ausgeführt wie der createBuild Aufgabe, was bedeutet, dass die built.txt Dateien, die der Packager erwartet, stehen ihm zur Verfügung.

Fahre fort und sparen und Jetzt bauen, und dann das ansehen Konsolenausgabe.

Alles lief wie erwartet - unser Baumeister wurde geklont und lief, und unser Packager wurde geklont und lief. Und wenn wir uns die Ausgabe ansehen, dann ist es da! Der Balrog von Morgoth wurde vollständig Gandalf'd.

Cool, aber ist das nicht ein bisschen…

Gekünstelt? Ganz sicher.

Ein komplexes Konzept ist jedoch nur ein Bündel einfacher Konzepte, die miteinander vermischt werden. Auf der Oberfläche versammelten wir Gandalfs Rede auf der Brücke von Khazad-dûm. Aber wirklich, wir haben die Build-Ausgabe eines Projekts genommen und in die Build-Ausgabe eines anderen Projekts eingefügt.

Was wäre, wenn anstelle von Gandalfs Dialog die Build-Ausgaben ausführbare Dateien aus separaten Codebasen wären, die alle für die von Ihnen gelieferte Software zusammengestellt werden müssen? Sie würden denselben Workflow verwenden, den wir hier eingerichtet haben: Klonen, Erstellen, Kopieren und Verpacken. Mit dem Jenkins Workflow-Plugin waren nur ein paar Zeilen Groovy erforderlich. Und als Bonus ist alles in einem einzigen Skript enthalten!

Es gibt auch andere Tools, mit denen Sie einen Jenkins Workflow verwalten und visualisieren können. CloudBees bietet eine Workflow Stage View-Funktion auf der Jenkins-Plattform für Unternehmen.

Dies verkratzt nur die Oberfläche dessen, was mit dem Jenkins Workflow-Plugin möglich ist. Schauen Sie sich die unten stehenden Links an, um mehr zu erfahren.

Viel Glück bei der Arbeit!