Parameterized Trigger

This plugin lets you trigger new builds when your build has completed, with various ways of specifying parameters for the new build.

These new builds appear as "Subprojects" in the Jenkins UI when you are looking at a project that triggers them.

You can add multiple configurations: each has a list of projects to trigger, a condition for when to trigger them (based on the result of the current build), and a parameters section.

There is also a Parameterized Remote Trigger Plugin in case you want to trigger a build on a different/remote Jenkins Controller.

The parameters section can contain a combination of one or more of the following:

• a set of predefined properties
• properties from a properties file read from the workspace of the triggering build
• the parameters of the current build
• Subversion revision: makes sure the triggered projects are built with the same revision(s) of the triggering build. You still have to make sure those projects are actually configured to checkout the right Subversion URLs.
• Restrict matrix execution to a subset: allows you to specify the same combination filter expression as you use in the matrix project configuration and further restricts the subset of the downstream matrix builds to be run.

The parameter section is itself pluggable, and other plugins can contribute other sources of parameters.

This triggering mechanism can be used both as a post-build step or as a build step, in which case you can also block for the completion of the triggered builds. This lets you create a "function call" like semantics.

When using the Trigger/Call builds on another project item. If the trigger is configured with the "Block until the triggered projects finish their builds" enabled, the following Environment variables are made available for further build steps.

Env variables for future build steps:

• LAST_TRIGGERED_JOB_NAME - Last project started
• TRIGGERED_BUILD_NUMBER_<project name> - Last build numbertriggered" (since 2.17)
• TRIGGERED_JOB_NAMES - Comma separated list of all triggered projects
• TRIGGERED_BUILD_NUMBERS_<project name> - Comma separated list of build numbers triggered
• TRIGGERED_BUILD_RESULT_<project name> - Last triggered build result of project
• TRIGGERED_BUILD_RESULT_<project name>*RUN*<build number> - Result of triggered build for build number
• TRIGGERED_BUILD_RUN_COUNT_<project name> - Number of builds triggered for the project

From 2.17 onwards: All Project names have characters not a-zA-Z or 0-9 replaced by _(multiple characters are condensed into a single).

Note that with the BuildStep a variable can be used for the project name, I.E. ${projectName}.

When using the trigger parameterized build as a post build task for a matrix job the triggering will be be done once when all of the different matrix configurations have completed. In this case some of the Environment variables may not be resolvable as passing them to downstream jobs will fail. You also cannot use a variable for the downstream project name. If this functionality is needed, the BuildStep must be used.

Environment variables that should be available are the the default shell ones (<yourserver:port>/env-vars.html) and ones defined as Parameters. Variables added by the other plugins as a buildwrappers may not be available.

When using the trigger parameterized build as a build step it will be called for every different configuration, so if triggering another project with no parameters it will be done the same number of times as you have configurations, possible causing the triggered job to run more than once.

However this also allows you to trigger other jobs with parameters relating to the current configuration, i.e. triggering a build on the same node with the same JDK.

• Git Plugin
• NodeLabel Parameter Plugin

• Since Parameterized Trigger 2.23, there are cases that Parameterized Trigger fails to trigger downstream builds that can be successfully triggered with Parameterized Trigger <= 2.22.
  • This is caused by the new behavior introduced in Parameterized Trigger 2.23. It gets to pass parameter values not directly to the downstream build, but to parameter definitions of downstream projects. This enables parameter definitions to perform its specific process, for example, selecting nodes with NodeLabel Parameter Plugin.
• Example: There is a project with a choice parameter with choices A, B, C. When you triggered that project with parameter value D, it fails with following output in the upstream:

    java.lang.IllegalArgumentException: Illegal choice: D at
    hudson.model.ChoiceParameterDefinition.checkValue(ChoiceParameterDefinition.java:72)

• This is the intended behavior.
  • As those failures are ones designed by parameter definitions. For example, the choice parameter is designed to not accept unexpected values.
  • The same behavior is visible builds are triggered those with the Jenkins CLI or the remote access API.
• It is recommended to fix your project configuration to have parameter definitions not fail.
  • For example, use EnvInject Plugin to process values or use Extensible Choice Parameter Plugin which provides a choice parameter accepting edited values.

Set the hudson.plugins.parameterizedtrigger.ProjectSpecificParametersActionFactory.compatibility_mode Java system property to true to restore the old behavior. Refer to the "Jenkins features controlled by system properties" for detailed instructions on Java system properties in Jenkins.

Please report issues and enhancements through the Jenkins issue tracker.