Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/jenkinsci/parameterized-trigger-plugin

Jenkins parameterized-trigger plugin
https://github.com/jenkinsci/parameterized-trigger-plugin

jenkins jenkins-builder jenkins-plugin jenkins-trigger

Last synced: 6 days ago
JSON representation

Jenkins parameterized-trigger plugin

Awesome Lists containing this project

README 

        
# Parameterized Trigger Plugin



[![Jenkins Plugin](https://img.shields.io/jenkins/plugin/v/parameterized-trigger.svg)](https://plugins.jenkins.io/parameterized-trigger)

[![GitHub release](https://img.shields.io/github/release/jenkinsci/parameterized-trigger-plugin.svg?label=changelog)](https://github.com/jenkinsci/parameterized-trigger-plugin/releases/latest)

[![Jenkins Plugin Installs](https://img.shields.io/jenkins/plugin/i/parameterized-trigger.svg?color=blue)](https://plugins.jenkins.io/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.



| WARNING: You must define the parameter in downstream jobs via the _This project is parameterized_ property. For example, if _job1_ passes `ABC=123` to _job2_ then in _job2_ mark the job as _This project is parameterized_ and add a parameter named `ABC`. See [this advisory](https://jenkins.io/blog/2016/05/11/security-update/) for more information |

| --- |



 #### Usage as a Build step



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_` - Last build numbertriggered" (since 2.17)

-   `TRIGGERED_JOB_NAMES` - Comma separated list of all triggered projects

-   `TRIGGERED_BUILD_NUMBERS_` - Comma separated list of build numbers triggered

-   `TRIGGERED_BUILD_RESULT_` - Last triggered build result of project

-   `TRIGGERED_BUILD_RESULT_*RUN*` - Result of triggered build for build number

-   `TRIGGERED_BUILD_RUN_COUNT_` - 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}`.



## Use of the plugin in a Matrix job



### Post build task



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 (`/env-vars.html`) and ones defined as Parameters.

Variables added by the other plugins as a buildwrappers may not be available.



### Build step



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.



## Plugins contributing additional parameter types to this plugin



* Git Plugin

* NodeLabel Parameter Plugin



## Backward compatibility with version 2.22



-   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.



### Workaround



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"](https://www.jenkins.io/doc/book/managing/system-properties/) for detailed instructions on Java system properties in Jenkins.



## Report an issue



Please report issues and enhancements through the [Jenkins issue tracker](https://www.jenkins.io/participate/report-issue/redirect/#15592).