Useful Jenkins plugins – Conditional BuildStep

The Conditional BuildStep plugin fills a need that I’ve felt in Jenkins for a long time: in the core Jenkins, there is no easy way to do conditional (if/then) logic. For example, in my installation I create parameterized builds, where one parameter is a dropdown list of environments to deploy to if the build succeeds. Deployment is then handled by a different Jenkins job.

Before Conditional BuildStep came along I tried some other workarounds. At first I used a shell script build step to evaluate the $DEPLOY_ENV environment variable. If it wasn’t the default value of “none,” I would use curl to trigger the downstream job via HTTP and pass it the appropriate parameters in the URL. There are two problems with this solution: first, since you’re triggering the deploy from the “build” phase of your first job, it happens before, and with no knowledge of, any of the post-build actions. Second, with this setup the first build job has no official connection to the deploy job, as far as Jenkins is concerned, so you can’t do things like make the build job wait and fail if the deploy fails.

Another approach that I used for a longer time was to use the Promoted Builds plugin in all my main build jobs. I created a sort of “shim” job that would evaluate $DEPLOY_ENV and fail if it was “none.” In my main build I set up Promoted Builds to trigger the shim job with the params from the main one, and if the shim was successful then trigger the deploy job. At least in this way the deploy happened after all the post-build steps in the main job, but I still had the problem of not being able to make the main job wait for the deploy to finish.

Conditional BuildStep was the answer to my prayers, and I’m now using it in two places in my builds. The first is in the build phase, to determine if we should create a package. Then, in the post-build phase, we use it to trigger the deploy job if appropriate. The configuration is not always that intuitive; here is a screenshot.

In this example, our build has a choice/dropdown menu parameter called DEPLOY_ENV where the user selects which environment they want to deploy to, if any. If they have chosen something then the first thing we need to do (after compiling and running tests, and assuming all that passes) is build a package.


Once a package has been built, in the post-build phase we want to trigger a deploy.

Due to a truly pernicious confluence of bugs that all interact with each other, there is no clean way to add a conditional build step as a post-build action. The resolution of JENKINS-14494 will help with that. I also use matrix/multi-configuration builds everywhere, which seem to be sort of the red-headed stepchild of Jenkins job types. There are many plugins that at best actively don’t support matrix jobs, or at worst just blow up when you try to use them in that context. Our solution is to use the PostBuildScript plugin, which lets you use build steps in a post-build context, in matrix jobs. It’s a plugin to call another plugin. Gross, but it works.

I will talk about matrix jobs more in an upcoming post.


Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *