Jenkins Plugin Implementation – Part 1

Total: 7 Average: 4.9

Jenkins Plugin implementation generally consists of the following stages:

  • Environment preparation;

  • Implementing the plugin’s UI;

  • Implementing the plugin’s business logic;

  • Implementing validation;

  • JUnit test coverage;

In this part of the article, we’ll look at the first two stages.

Environment preparation

Before starting the development of a Jenkins plugin, you would need to make sure that you have an environment prepared along the following guidelines:

  • JDK 8 is installed on your machine and the JAVA_HOME environment variable is set (this variable contains the path to JDK);

  • Apache Maven is installed;

  • An IDE that allows developing Jenkins plugins on Java is installed (e.g., IntelliJ IDEA).

Implemeting the plugin’s UI (front-end)

The plugin’s UI is configured through a Jelly file. Jelly is a specialized markup language that visually resembles xml and is widely used for writing plugins in Java.

The Jelly file is created within the project’s resources and is usually named config.jelly. To make sure Java will properly link this file to the plugin’s implementation, you will need to make sure that the UI folder you create in the project’s resources will have the same name as the Java file containing the plugin’s business logic. For example, if the plugin’s logic is implemented in the src/main/java/org/myorganization/ class, the UI should be then implemented in the src/main/resources/org/myorganization/MyAction/config.jelly file.

As Jelly files are directly connected with the Java classes, you can call the methods from these classes in Jelly. To reference the Java files they’re connected with, Jelly files use the it or instance keyword – “${it.[member of classes]}”.

Suppose there is a method defined in a Java class:

To call this method in Jelly, we will need to do the following:

Depending on the plugin type, other objects can also be predefined:

  • app – the Jenkins instance.

  • instance – the Java class object that is currently being configured in the configuration page section.

  • descriptor – the descriptor object that corresponds to the instance class.

  • h – the hudson.Functions instance containing various useful functions.

Also, when writing UI in Jelly files, you can use resource constants. To do this, create a resource file next to the Jelly file. When this is done, the resource constants will be available for use in the ${%resourceName} format. For example:

The help functionality in Jenkins is realized in the following way. An html file with a ‘help-’ prefix (e.g., help-FIELD.html) is formed in the webapp folder of our plugin’s project. To connect the help file with a specific field, the help=”path to help file” statement is used. For example:

Also, when you’re designing UI, it is important to keep in mind that you won’t need to constantly restart the Jenkins server in most of the cases – instead, just change the *.jelly file in your IDE and request the page again.

Links you may find useful when designing UI in Jelly:

Apache Jelly Tutorial

Basic guide to Jelly usage in Jenkins

Jelly form controls

We’ll look at the remaining stages of Jenkins plugin implementation in the second part of this article.

Artem Kravets

Latest posts by Artem Kravets (see all)