Das Pipeline Plugin (früher Workflow Plugin) für Jenkins revolutioniert die Arbeit mit Jenkins, indem es das Erstellen von Build Jobs als Code ermöglicht. Dadurch werden Build Pipelines unter anderem wiederverwendbar, versionierbar, testbar und einfacher lesbar als etwas “Zusammengeklicktes“.

Um die auf Groovy basierende Jenkins Pipeline Domain Specific Language (DSL) explorativ zu erlernen und auch später effizient damit zu arbeiten, ist Code-Vervollständigung sehr hilfreich. Dieser Artikel zeigt wie sich dies in wenigen Schritten mit IntelliJ IDEA realisieren lässt.

Bei der Verwendung des Pipeline Plugins ist es Konvention, die Pipeline in der Datei Jenkinsfile zu beschreiben. Wer sich an diese hält, bekommt die halbe Miete der Code-Vervollständigung von IDEA geschenkt – der Dateiname Jenkinsfile ist bereits mit der Programmiersprache Groovy assoziiert. Dadurch hat man bereits Code Vervollständigung für alle Groovy-Sprachkonstrukte.

Bezüglich der Pipeline DSL hilft dies aber nicht weiter. Die hier verfügbaren Sprachkonstrukte hängen davon ab welche Plugins auf der jeweils verwendeten Jenkins-Instanz installiert sind. Daher muss diese Information auch von dort bezogen werden. Das Pipeline Plugin stellt dafür eine Beschreibung in Form einer Groovy DSL Script (GDSL-) Datei bereit. Diese kann unter

https:///job//pipeline-syntax/gdsl

heruntergeladen werden. Wenn Jenkins beispielsweise unter localhost läuft und ein Job myproject eingerichtet ist, lautet die URL zur GDSL

https://localhost/job/myproject/pipeline-syntax/gdsl

Damit diese von IntelliJ gelesen wird, muss sie in einem Source-Ordner mit der Endung .gdsl gespeichert werden, beispielsweise unter src/main/groovy/jenkins.gdsl. Abhängig vom Ordner und Projekt muss dieser Ordner noch unter File | Project Structure | Modules | als Sources Ordner gekennzeichnet werden. Spätestens dann sollte im Jenkinsfile folgendes möglich sein:

 

Getestet mit IntelliJ 2017.1.2 und Jenkins ver. 2.46.2.

Kommentare

Keine Kommentare

Ähnliche Beiträge

Mutation Testing mit Pitest

Autor
  • Philipp Czora
Publiziert

Codequalität und -korrektheit lassen sich unter anderem mit Hilfe von Unit-Tests sicherstellen. Aber nicht jeder Unit-Test ist sinnvoll und häufig schaffen es Bugs von Unit-Tests unerkannt zu bleiben. Wie lässt sich die Testqualität erhöhen, um Programmierfehler zuverlässiger und früher zu erkennen?

Eine Groovy-DSL zum Erzeugen von Testdaten über JPA

Autor
  • Daniel Behrwind
Publiziert

Beim automatisierten, integrativen Testen von Software, die mit einem komplexen JPA-Datenmodell arbeitet, steht man unweigerlich früher oder später vor der Frage, wie sich semantisch sinnvolle Testdaten ohne großen Aufwand erzeugen lassen. Dieser Artikel zeigt, wie man mit Groovy eine Domain Specific Language (DSL) definieren kann, die es erlaubt, Testdaten leicht lesbar, modular und getrennt vom eigentlichen Test-Code zu definieren.

Statische Codeanalyse mit SonarQube

Autor
  • Josha von Gizycki
Publiziert

Manchmal fragen sich Entwickler: „Was mache ich hier eigentlich?“ Das hat dann nichts mit einer plötzlichen Sinneskrise oder dem Zusammenbruch der persönlichen Weltanschauung zu tun. Vielmehr wacht der innere Softwarearchitekt auf und verlangt nach einer Darstellung des Großen Ganzen.

SLF4J und Logback in Android

Autor
  • Johannes Schnatterer
Publiziert

Wenn man als Java-Entwickler in die Android-Entwicklung einsteigt, ist zunächst vieles aus Java bekannt. Einige Aspekte sind aber auch anders gelöst. So zum Beispiel das Thema Logging. Hier bringt Android seine eigene API mit, die ohne weitere Konfiguration bequem verwendet werden kann. Bei fortgeschrittenen Herausforderungen zeigt dieser Ansatz jedoch seine Grenzen. Hier kann auf vorhandenes Wissen und Bibliotheken aus der Java-Welt zurückgegriffen werden.