Build Pipeline

Build Pipeline Plugin 1.3.0 Release

Posted on

New release

About a year after the last official update and after some unofficial releases, we are happy to announce a new release of the Build Pipeline Plugin.  This new version is meant to be more visual and responsive.  The release also includes a Build Pipeline Dashboard View to be used with the Dashboard View Plugin.  In addition, various bugs have been fixed and various features have been implemented.  We would like to thank our contributors and we hope this new release improves your experience with the Build Pipeline Plugin.

Pipeline version

Another thing we should mention is the build pipeline version.  Our initial intention was to display the Source Control Management (SVN, GIT, HG, etc) version of the checked out code of the first build in the pipeline.  This proved to be a challenge since various SCM plugins seemed to implement getting the SCM version differently and Jenkins SCM abstract classes did not seem to force SCM plugins to provide methods to get this info in a uniform way.  Furthermore, various users did not care for the SCM version to be displayed as the version of the pipeline and in other cases it simply did not make sense (if people checked out code at each build steps rather than use the clone workspace plugin).  Thus, following the example of one of our contributors, we simply used the build number of the first job as the pipeline version.  We felt that it simplified things from our end while still providing a unique number for when a pipeline was executed.  We hope that this approach will satisfy most users.

Release notes


Publishing to Jenkins and Hudson – ease versus control

Posted on

The split

The popular open source continuous integration server, Hudson, forked a few months ago.  Its creator, Kohsuke Kawaguchi, along with a larger part of the open source community forked Hudson and created Jenkins. As for Hudson, it is now under the Oracle and Sonatype umbrella.

In the meantime, we at Centrum Systems were writing the build pipeline plugin.  Not wanting to take sides, we decided to release the plugin to both Hudson and Jenkins.  Having released version 1.0.0 of the plugin and receiving a lot of positive and constructive feedback, we wanted to correct some problems with the plugin, while adding some requested features.  I’ll try and summarize our experience of releasing the plugin to either platform.


  1. Publish the plugin using the same mechanism we used to publish 1.0.0
  2. Realize the old process changed since the plugin was deployed to the same repository but it would not appear in Hudson’s update center
  3. Read the new release process and comply to it
  4. Create a JIRA user
  5. Miss a few points and ask Oracle for some help
  6. Create a JIRA ticket expressing our willingness to publish the plugin
  7. Wait for someone to address the ticket and give us rights to publish to the staging repository
  8. Change the build to ensure the artifacts were signed as per the following instructions
  9. Publish the plugin using release:prepare, release:perform (and the corresponding deployment management configuration as described in step 3)
  10. Log on to Sonatype’s Nexus instance and “close” the deployment (some verifications were performed on the plugin)
  11. The verification failed and I needed to publish our public key to a keys server (actually, the error message was really clear and helpful)
  12. “Release” our plugin within Sonatype’s Nexus workflow (a single click, similar to step 10)
  13. Comment on the original JIRA ticket to ask them to release the plugin for real (to the maven 2 repo)
  14. Wait a while for the JSON file listing all Hudson plugins to be updated and show the availability of a new version

Elapsed time: About 6 working days


  1. Publish the plugin using the same mechanism we used to publish 1.0.0 (create an account, add the distribution management information in the pom file, update the settings.xml file with the server information)
  2. Wait a few hours for the JSON file listing all Jenkins plugins to be updated  and show the availability of a new version

Elapsed time: A few hours


I can certainly appreciate the steps to sign the plugin and the extra validations ensuring the plugin has all the right elements, but the Hudson process felt a bit heavy.  Hopefully the next release will not be as tedious since we learned quite a bit during the exercise.  Finally, I would like to thank Winston from Oracle since he was helpful and responsive and all other people involved in the process.  I would also like to thank the Jenkins people since the publishing process was nice, streamlined and uneventful (in a good way).

The fact that Jenkins has had 11 new versions whilst Hudson has had only 2 since the fork is indicative of the different approaches.


Posted on

Following great community feedback about the Build Pipeline Plugin 1.1.1, we are pleased to announce the availability of version 1.1.2.  The release addressed a few bugs and expanded its SCM support (namely Git and Mercurial).


The following defects have been resolved. Remaining defects are visible from the google code issue tracker (

Defect ID Summary
2 Support Git SHA1 for “revision”
16 Add date/time of execution
19 Build view empty, NPE in the log
22 Support for mercurial revision number
27 Build Pipeline and Copy Artifact plugin combination causes NPE

Build Pipeline Plugin

Build Pipeline Plugin Release 1.1.1

Posted on

At Centrum Systems we were curious to see the response of the initial release of the Hudson/Jenkins build pipeline plugin by the community. We were pleased with the uptake and received some brilliant feedback including bugs and enhancement requests. Yesterday we published a minor update to the plugin that resolves the majority of the issues as well as offering some new capabilities.

New Features

The major improvements we achieved as part of release 1.1.1 are:

  1. Improved GUI

    The GUI has been completely revamped to improve usability and build pipeline display. New features are:

    • The whole display is now centred with each build pipeline being clearly displayed.
    • Each build has a cleaner look displaying important build information.
    • The job and build information is hyperlinked to the respective pages.
    • Links have been added to:
      • Navigate to the view configuration page
      • Invoke a new build of the pipeline
  2. Support for Parallel Downstream Jobs

    You can now create multiple downstream projects from the same upstream project. This includes multiple downstream splits as shown below.

    Split Pipeline
    Split Build Pipeline
  3. Support for Automatic and Manual trigger Downstream Jobs

    You can now create both automatic and/or manually triggered downstream build steps on the same project.

  4. Support for Hudson/Jenkins Security Settings
  5. Improved overall plugin stability

Bug Fixes

The following defects have been resolved. Remaining defects are visible from the google code issue tracker (

Defect ID Summary
1 Manual execution ignores security settings
3 Support for parallel downstream jobs and joins
4 Pipelines seem to be repeated to fill “No Of Displayed Builds”
5 Images not working in view if using –prefix
6 Configure errors
7 Manual build checkbox losing its value
8 Build pipeline revision box does not display SVN revision number
10 Images not found
11 Descriptions not being saved
12 Incorrect job paths
14 Pipeline doesn’t stop when one job fails
18 Can’t select any job as root

Known Limitations

Future Work


The documentation is available from the Hudson and Jenkins wikis.

Build Pipeline (Hudson & Jenkins) Plugin 1.0.0 Released

Posted on

We are pleased to announce that we are donating the Centrum build pipeline plugin to the open source community.  This is a plugin developed for the popular Hudson and Jenkins Continuous Integration servers.

This was developed to assist with the orchestrating the promotion of a version of software through quality gates and into production. By extending the concepts of CI you can create a chain of jobs each one subjecting your build to quality assurance steps. These QA steps may be a combination of manual and automated steps. Once a build has passed all these, it can be automatically deployed into production.

Release Management, Continuous Integration, Automated Testing and Deployment Automation are all links in a chain that need to work together to get to high quality, low risk software deliveries.


The documentation is available from the Hudson and Jenkins wikis.


build pipeline
build pipeline