For those of you running Workflow on Jenkins 1.609.x, I have released version 1.9 with a variety of fixes and enhancements . CloudBees Jenkins Enterprise customers running the 1.3 extensions should upgrade to 1.4 at the same time to ensure that checkpoints continue to work, as well as getting some other bug fixes.
But the interesting work is on multibranch projects. If you enable the experimental update center (CJE customers need only check a box in system configuration to do this), you can install a beta of the Workflow: Multibranch plugin (this will pull in Branch API Plugin too). This will add a new item type you can create in Jenkins: Multibranch Workflow .
When you have a multibranch workflow, the configuration screen will resemble Groovy CPS DSL from SCM in that your Workflow script comes from source control, not the Jenkins job configuration. The difference is that you do not configure a single branch, but a set of branches, and Jenkins creates a subproject for each branch it finds in your repository.
For example, if you select Git as the branch source (Subversion and Mercurial are also supported already), you will be prompted for the usual connection information, but then rather than a fixed refspec you will enter a branch name pattern (use the defaults to look for any branch). Jenkins expects to find a script named jenkins.groovy (probably soon renamed to Jenkinsfile ) in branches it can build. From this script, the command checkout scm suffices to check out your project’s source code inside some node {} .
Say you start with just a controller branch, then you want to experiment with some changes, so you git checkout -b newfeature and push some commits. Jenkins will automatically detect the new branch in your repository and create a new subproject for it—with its own build history unrelated to trunk, so no one will mind if it has red/yellow balls for a while. (If you like, you can ask for the subproject to be automatically removed after the branch is merged and deleted.)
The neat thing is that if you want to change your Workflow script—for example, to add a new Jenkins publisher step corresponding to reports your Makefile /pom.xml /etc. is newly creating—you just edit jenkins.groovy in your change. The Workflow script is always synchronized with the rest of the source code you are working on: checkout scm checks out the same revision as the script is loaded from.
The stock “CD” demo has been updated to use this system, too. That is the easiest way to see it in action.
We hope to add more features and integrations in this area soon, and there is plenty of spit & polish needed (not to mention proper documentation), but I wanted to send out a summary for those eager to experiment.
Jesse Glick
Developer
CloudBees