http://jenkins.acme.org/job/myjob/buildWithParameters?PARAMETER=ValueSo, in the example shown above, you could trigger a build like this:
http://jenkins.acme.org/job/parameterized-build/buildWithParameters?VERSION=1.2.3When you use a URL to start a build job in this way, remember that the parameter names are case-
sensitive, and that the values need to be escaped (just like any other HTTP parameter). And if you are
using a Run parameter, you need to provide the name of the build job and the run number (e.g., game-
of-life#197) and not just the run number.
10.2.7. Parameterized Build Job History
Finally, it is indispensable to know what parameters were used to run a particular parameterized build.
For example, in an automated deployment build job, it is useful to know exactly what version was
actually deployed. Fortunately, Jenkins stores these values in the build history (see Figure 10.14,
“Jenkins stores what parameter values where used for each build”), so you can always go back and take
a look.
Figure 10.14. Jenkins stores what parameter values where used for each build
10.3. Parameterized Triggers
When you trigger another build job from within a parameterized build job, it is often useful to be able
to pass the parameters of the current build job to the new one. Suppose, for example, that you have an
application that needs to be tested against several different databases. As we have seen, you could do
this by setting up a parameterized build job that accepts the target database as a parameter. You may
want to kick of a series of builds, all of which will need this parameter.
If you try to do this using the conventional “Build other projects” option in the Post-Build Actions
section, it won’t work. In fact, you can’t trigger a parameterized build in this way.
However, you can do this using the Jenkins Parameterized Trigger plugin. This plugin lets you configure
your build jobs to both trigger parameterized builds, and to pass arbitrary parameters to these builds.