The Pipeline plugin (formerly Workflow plugin) for Jenkins revolutionises working with Jenkins by allowing for the creation of build jobs as code. As a result, build pipelines can be put under version control, become reusable,testable and more easily readable, among other things, as something “put together with mouse clicks”.

In order to learn the Jenkins Pipeline domain specific language (DSL) in an exploratory way as well as to work with it more efficiently later, code completion is very helpful. This article demonstrates how this can be realised with IntelliJ IDEA in just a few steps.

When using the Pipeline plugin, it is a convention to describe the Pipeline in a file called Jenkinsfile. Anyone who sticks to this is already halfway to code completion by IDEA – the Jenkinsfile filename is already associated with the Groovy programming language. As a result, you already have code completion for all Groovy language constructs.

However, this doesn’t help at all when it comes to the Pipeline DSL. The language constructs available here depend on which plugins are installed in the instance of Jenkins being used. Consequently, this information must also be obtained from there. For this, the Pipeline plugin provides a description in the form of a Groovy DSL script (GDSL) file. This can be downloaded from

https://<Jenkins>/job/<Job Name>/pipeline-syntax/gdsl

If, for example, Jenkins runs under localhost and a job myproject is set up, the URL for the GDSL file is

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

In order for this to be read by IntelliJ, it must be saved in a source folder with the suffix .gdsl, for example under src/main/groovy/jenkins.gdsl. Depending on the folder and project, this must still be designated as a sources folder under File | Project Structure | Modules. Then, the following should be possible in Jenkinsfile:

 

Tested with IntelliJ 2017.1.2 and Jenkins ver. 2.46.2.

Comments

No Comments

Related Posts

Mutation Testing with Pitest

Author
  • Philipp Czora
Published

Unit tests can be useful for ensuring code quality and correctness. Not every unit test makes sense, however, and bugs often manage to escape detection by unit tests. How can test quality be increased so that programming errors are detected earlier and more reliably?

A Groovy DSL for the Creation of Test Data using JPA

Author
  • Daniel Behrwind
Published

With the automated integrative testing of software that works with a complex JPA data model, it is invariably the case that sooner or later, one will face the question of how it is possible to create semantically meaningful test data without great cost. This article shows how Groovy can be used in order to define a Domain Specific Language (DSL) that enables test data to be defined so that it is easily readable, modular and separate from the actual test code.ieren.

Static code analysis with SonarQube

Author
  • Josha von Gizycki
Published

This article describes which key figures can be collected by a static analysis and how these can be interpreted. The main focus is on technical debt and complexity.