This document, together with the hello-world plugin, shows you how to get started with the plugin development.
Please first read the "before writing a plugin" page.
There are a lot of existing Jenkins plugins, and a lot of people with Jenkins plugin development experience that you can take advantage of!
Check whether there is an existing plugin you can already use, or contribute to, then get in touch via the jenkinsci-dev mailing list, or IRC and explain your plugin idea.
Jenkins defines extensibility points, which are interfaces or abstract classes that model an aspect of a build system. Those interfaces define contracts of what need to be implemented, and Jenkins allows plugins to contribute those implementations. See this document for more about extension points.
In this document, we'll be implementing a Builder that says hello. (built-in builders include Ant, Maven, and shell script. Builders build a project.)
To develop a plugin, you need Maven 3 (why?) and JDK 6.0 or later. If this is the first time you use Maven, make sure Maven can download stuff over the internet.
It may be helpful to add the following to your ~/.m2/settings.xml (Windows users will find them in %USERPROFILE%\.m2\settings.xml):
This will let you use short names for Jenkins Maven plugins (i.e. hpi:create instead of org.jenkins-ci.tools:maven-hpi-plugin:1.61:create),
To start a new plugin, use the online skeleton generator, or use an IDE (below).
This will ask you a few questions, like the groupId (the Maven jargon for the package name) and the artifactId (the Maven jargon for your project name), then create a skeleton plugin from which you can start with. Make sure you can build this:
-U means that Maven should update all relevant Maven plugins (check for plugin updates)
To build a plugin, run mvn install. This will create the file ./target/pluginname.hpi that you can deploy to Jenkins.
NetBeans users can use the IDE's Maven support to open the project directly.
As you navigate through the code, you can tell NetBeans to attach source code JAR files by clicking the "Attach" button that appears in the top of the main content window. This allows you to read the Jenkins core source code as you develop plugins. (Or just select Download Sources on the Dependencies node.)
You are advised to use the NetBeans plugin for Jenkins/Stapler development. This offers many Jenkins-specific features. Most visibly, create a new plugin using New Project » Maven » Jenkins Plugin, and use Run Project to test it.
IntelliJ 7.0 (or later) users can load pom.xml directly from IDE, and you should see all the source code of libraries and Jenkins core all the way to the bottom. Consider installing IntelliJ IDEA plugin for Stapler to make the development easier.
Use Eclipse Juno (4.2) or later for the best experience.
As Jenkins plugins are Maven projects, Eclipse users have two ways to load a Jenkins plugin project. One is to use m2e, which tries to make Eclipse understand Maven "natively", and the other is to use Maven Eclipse plugin, which makes Maven generate Eclipse project definitions. At the moment, unless you have some prior experience with m2e, we currently recommend plugin developers to go with the Maven Eclipse plugin.
Eclipse users can run the following Maven command to generate Eclipse project files (the custom outputDirectory parameter is used to work around the lack of JSR-269 annotation processor support in Eclipse:)
Where /path/to/workspace is the path to your Eclipse workspace.
Once this command completes successfully, use "Import..." (under the File menu in Eclipse) and select "General" > "Existing Projects into Workspace".
See Jenkins plugin development with Eclipse for gotchas and other known Eclipse/Maven related issues with Jenkins plugin development.
See Eclipse alternative build setup for an alternative way of setting up the Eclipse build environment, that is a bit more technically involved than using maven, but can give faster build times.
The plugin workspace consists of the following major pieces:
Maven uses it for building your plugin.
Java source files of the plugin.
Jelly/Groovy views of the plugin. See this document for more about it.
Static resources of the plugin, such as images and HTML files.
(deprecated in favor of the Extension points approach below)
A plugin's main entry point may be a PluginImpl class that extends from Plugin. Once Jenkins detects this plugin class (via its inheritance relationship from Plugin), it will create an instance, and invoke methods.
The bulk work in the plugin consists in implementing those extension points. See the sample source code for more information about how a Builder is implemented and what it does.
Here are a few things about extension:
NetBeans 6.7+ users can just hit Debug. For all others, run the following command to launch Jenkins with your plugin:
If you open http://localhost:8080/jenkins in your browser, you should see the Jenkins page running in Jetty. The MAVEN_OPTS portion launches this whole thing with the debugger port 8000, so you should be able to start a debug session to this port from your IDE.
Once this starts running, keep it running. Jetty will pick up all the changes automatically.
If you need to launch the Jenkins on a different port than 8080, set the port through the system property jetty.port.
maven-hpi-plugin 1.65 or later (used by parent POM 1.401 or later) can set the context path by using a system property. On more recent versions of Jenkins the "/jenkins" prefix is added automatically.
Depending on what you change, you can see it in the running instance without restarting the whole Maven process:
To create a distribution image of your plugin, run the following Maven command:
This should create target/*.hpi file. Other users can use Jenkins' web UI to upload this plugin to Jenkins (or place it in $JENKINS_HOME/plugins.)
If you got to this point, you should definitely consider hosting your plugin on jenkins-ci.org. Move on to this document for how to do that. This includes the instructions for releasing the plugin.
If you are building a patched version of one of the plugins in the Jenkins core, the deployment process is a bit different. This is because Jenkins will itself manage these plugins unless you tell it not to.
Besides this tutorial, there are other tutorials and examples available on line:
Skip to end of metadata Go to start of metadata