Contributing to the Pipeline plugin
The license is MIT. New significant source files (usually
*.java) should carry the MIT license header.
For bug fixes and enhancements to existing Pipeline features, first make sure an issue is filed. JIRA query for open Pipeline-related issues
Determine the plugin, and thus repository, where the change should be made; for example,
Then you can file a pull request with your change. (Link to the JIRA issue in the PR, and link to the PR from the JIRA issue.) Please keep the patch as short as possible to make it easier to review, as well as minimizing the chance of merge conflicts. In particular, do not include diff hunks which merely change whitespace or reformat lines not otherwise edited. PRs should include test coverage for the fix or enhancement whenever feasible.
The procedure would be the same for major new features or refactorings, but you probably want to get advance feedback on the design.
You can use the Jenkins developer list, or contact a maintainer such as
#jenkins IRC, etc.
If you want to contribute new Pipeline steps, consider adding them to an existing plugin which already covers similar functionality. For general-purpose steps, consider the Pipeline Utility Steps plugin. See also the plugin compatibility guide.
- Ongoing plugin compatibility list
- Video tutorial on implementing a Step API
- Video walkthrough of code
Running from sources
If you want to try running recent development changes, rather than released binaries, you have two options. You can run directly from a source tree; from the root of a plugin repository:
Then visit http://localhost:8080/jenkins/ to play with the plugins.
(If your IDE supports compile-on-save mode this is especially convenient since each
hpi:run will pick up compiled changes without needing to run to
You can also run the basic Docker demo with snapshot binaries:
- (re-)build one or more component plugins using
mvn -DskipTests clean install
- specify a
make -C workflow-aggregator-plugin/demo run
(A similar procedure works for other Docker-based demos, such as in
The snapshot Docker demo is mainly useful for verifying the effect of ongoing changes on future demo binary releases.
You get the
cd sample job set up, but your environment is thrown away if you kill the Docker container (for example with Ctrl-C).
hpi:run the same
work/ home directory is reused so long as you do not explicitly delete it.
The implementation is divided into a number of plugin repositories which can be built and released independently in most cases.
workflow-step-api-plugindefines a generic build step interface (not specific to pipelines) that many plugins could in the future depend on.
workflow-basic-steps-pluginadd some generic step implementations.
workflow-api-plugindefines the essential aspects of pipelines and their executions. In particular, the engine running a Pipeline is extensible and so could in the future support visual orchestration languages.
workflow-support-pluginadds general implementations of some internals needed by pipelines, such as storing state.
workflow-job-pluginprovides the actual job type and top-level UI for defining and running pipelines.
workflow-durable-task-step-pluginallows you to allocate nodes and workspaces, and uses the
durable-taskplugin to define a shell script step that can survive restarts.
workflow-scm-step-pluginadds SCM-related steps.
pipeline-stage-step-pluginadd complicated steps.
pipeline-stage-view-pluginadds a job-level visualization of builds and stages in a grid.
workflow-cps-pluginis the Pipeline engine implementation based on the Groovy language, and supporting long-running pipelines using a continuation passing style transformation of the script.
workflow-cps-global-lib-pluginadds a Git-backed repository for Groovy libraries available to scripts.
workflow-aggregator-pluginis a placeholder plugin allowing the whole Pipeline suite to be installed with one click. It also hosts the official Docker demo.