You can also see a history of pipelines in a view, the current status and where each version got to in the chain based on it's revision number in VCS.
We'd love to hear about your experience using it or any enhancement suggestions - please let us know:
- Twitter: @CentrumSystems
- Email: firstname.lastname@example.org (mailto: email@example.com)
Widget Connector url http://twitter.com/CentrumSystems
The Pipeline View
Navigate to the configure view page.
Start Build of Pipeline for ...
Invokes a new build of the initial job in the build pipeline.
View/Hide Build Pipeline Icon Legend
Toggles the view of the Build Pipeline Icon legend.
- Install the plugin using the Hudson\Jenkins update centre Plugin Manager and restart.
- Create a view of the new type "Build Pipeline View". Note: it doesn't take you directly to it's configuration page
- To get to the configuration options, you must go to the configuration page directly. E.g.http://localhost:8080/view/new-view/configure (if your view happens to be called "new-view")
- The .
You will then be redirected directly to the configuration page.
- The table below outlines what each interesting parameter controls:
The name of the Build Pipeline View
This message will be displayed on the view page. Useful for describing what this view is about, or linking to relevant resources. Can contain HTML tags.
Build Pipeline View Title
Gives a title to the page that displays the view
Select Initial Job
This is the first job in the chainbuild pipeline. It will traverse through the downstream jobs to build up the entire build pipeline.
Select from a drop-down list of jobs.
No of Displayed Builds
The number of historical builds to be displayed on a page
Manual downstream build step configuration
In order to make the next build in the chain manual, check the "require manual build execution" checkbox in the Post Build action section of the job configuration.
- Navigate to the Job configuration page.
- Scroll down to the Post-build Actions section.
- For an Automated downstream build step;
To add a build step that will trigger automatically upon the successful completion of the previous one
- For an Automated downstream build step;
- Project Build Trigger
- Build Other Projects Post Build action
- Select the Build other projects check-box
- Enter the name(s) of the downstream projects in the Projects to build field. (n.b. Multiple projects can be specified by using comma, like "abc, def".)
- For a Manually Triggered downstream build step:
To add a build step that will wait for a manual trigger:
- Select the Build Pipeline Plugin -> Manually Execute Downstream Project check-box
- Enter the name(s) of the downstream projects in the Downstream Project Names field. (n.b. Multiple projects can be specified by using comma, like "abc, def".)
- Click Save
The Build Pipeline Plugin handles the creation of multiple automatic and/or manually triggered downstream build steps on the same project.
Upgrading from Release 1.0.0
When upgrading from 1.0.0 to 1.1.1 some of the previous view and job configuration fields have been removed. You may notice some errors of the following errors appearing in the Hudson/Jenkins log.
WARNING: Skipping a non-existent field downstreamProjectName com.thoughtworks.xstream.converters.reflection.NonExistentFieldException: No such field au.com.centrumsystems.hudson.plugin.buildpipeline.trigger.BuildPipelineTrigger.downstreamProjectName
This is because the configuration files refer to old fields that may no longer exist.
In order to correct these issues go to the Job configuration page, confirm that all of the details are correct and click on the Save button.
This is hosted on Google Code so that we can support both Jenkins and Hudson.
Please use Google Code rather than this page to ask questions, report bugs and request features.
- It takes a long time for projects or new development resources to become productive.
- Inability to scale resources or development partners to meet business demands.
- Inconsistent quality of software deliverables across project teams or suppliers.
- Error prone manual build processes which are difficult to scale
- Inconsistent application of tools and processes resulting in key resource dependencies.
- Dependency on hero factor in software deployments – asking too much of individuals to successfully implement software.
- Uncertainty around the impact of change
- Lack of visibility of the quality or status of change until late in the delivery lifecycle.
- Spiralling costs of change due to ever increasing technical debt
Centrum Systems have developed an offering we call Software Delivery Mastery (SDM). We can help in the following areas:
For information about how we can help you please contact us or visit www.centrumsystems.com.au