Useful Jenkins plugins – Parameterized Trigger

This will be the first in a series of posts about Jenkins plugins that I like and use heavily. A big part of the value in Jenkins is the great collection of plugins that exist for it, though you do have to watch out for ones that are buggy or have been abandoned.

The Parameterized Trigger plugin lets you trigger other builds and pass parameters to them which can be used in their configurations. This assumes that the downstream jobs are configured with parameters. You can do this as a build step or a post-build step. In our case, we use it in the post-build process of all our build jobs, to optionally deploy the built code to one of several test environments.

Our build jobs all have parameters of git branch name (defaults to master) and deploy environment (defaults to none). If you choose an environment when you build, it causes the job to create a package if the build (compilation and tests) is successful. During the package step, we write (echo from a shell) a Java properties file, which is just a text file of key/value pairs, one per line, in the form ‘key=value.’ We store the keys package_name, version_number, and deploy_environment in that. In the post-build phase, we add a ‘Trigger parameterized build on other projects’ step. It calls the ‘util_deploy’ job, only when the current build is stable, and sends the build properties file that I created earlier.


Screen shot 2013-05-07 at 2.57.24 PM

The util_deploy job has parameters of package_name, version_number and deploy_environment. It runs a shell script which takes those variables and kicks off a deploy as requested. The console output of the parent job will include a link to the deploy job, so users can quickly jump there and look at the log if something went wrong.

Parameterized Trigger is, by my informal estimate, one of the most widely-used Jenkins plugins. It was downloaded over 10,000 times in April of this year alone. It gives you a much more powerful way to chain Jenkins jobs together than the built-in ‘Build other projects’ step, because once you can actually pass data around between them you can do almost anything you want. You don’t have to create a ‘properties’ file, either. You can just choose to pass all the parameters/values your parent job has, the Subversion revision or Git commit that was used in the build, or arbitrary parameters that you define.


Bookmark the permalink.

Leave a Reply

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