Skip to main content
← Back to workflows

How to Automatically Trigger Builds with Parameters in Jenkins?

parameterized-trigger -
Jenkins Plugin
v.806.vf6fff3e28c3e
71
Required Jenkins: v.2.426.3
ID: parameterized-trigger
Contributors
Contributor - ikedamContributor - MarkEWaite
Categories
CICUBE ANALYTICS INSIGHTS
Engineering Velocity: 25% Team Time Lost to CI Issues
View Platform →
3.5h
Time Saved/Dev/Week
40%
Faster Releases
Click for next insight
Installation with the CLI tool
jenkins-plugin-cli --plugins parameterized-trigger:787.v665fcf2a_830b_

parameterized-trigger-plugin logo

Parameterized Trigger

The Parameterized Trigger Plugin in Jenkins allows automated triggering of builds with customizable parameters.


What is Parameterized Trigger?

This plugin is super helpful for automating our build processes by triggering new builds under specific conditions.

Key Features:

  • Triggering New Builds: You can set up new builds to start automatically once a current build completes, using various parameters.
  • Subprojects Visibility: These triggered builds appear as "Subprojects" in the Jenkins UI under the project that triggers them.
  • Multiple Configurations: It allows multiple configurations per project. You can specify which projects to trigger, under what conditions (based on the results of the current build), and the parameters for these new builds.
  • Parameter Sources: You can define parameters using predefined properties, from a properties file in the workspace, or directly from the parameters of the current build.
  • Subversion Coordination: Ensures that triggered projects use the same Subversion revisions as the triggering build.
  • Matrix Builds Control: Allows restricting matrix execution to a subset, using filter expressions similar to those used in matrix project configurations.
  • Remote Triggers: There's also a Parameterized Remote Trigger Plugin for triggering builds on different or remote Jenkins Controllers.

How to Use Parameterized Trigger?

This plugin is great for managing dependencies between projects by allowing us to trigger other builds directly from our current job configuration.

Usage as a Build Step:

  • Triggering Builds: You can trigger builds on other projects directly from a build step. If you set it to "Block until the triggered projects finish their builds," you'll have access to various environment variables which can be useful for subsequent build steps or conditions.
  • Environment Variables:
    • LAST_TRIGGERED_JOB_NAME - the name of the last project that was triggered.
    • TRIGGERED_BUILD_NUMBER_<project name> - the build number of the last triggered project.
    • TRIGGERED_JOB_NAMES - a comma-separated list of all triggered projects.
    • Other variables related to build results and counts are available, formatted appropriately for each triggered project.
  • Matrix Job Integration:
    • If used as a post-build task in a matrix job, it triggers only once after all configurations have completed. Note that not all environment variables might resolve in this scenario due to the nature of matrix builds.
    • As a regular build step, it can trigger builds for each matrix configuration, which might lead to multiple triggers if not managed correctly.

Special Notes:

  • From version 2.17, project names in variables are sanitized to remove non-alphanumeric characters, replacing them with underscores.
  • Variables from other plugins or build wrappers might not be available in the triggered builds.

This setup can significantly enhance our build process by automating the triggering of dependent builds based on the completion or parameters of a current build.