Child pages
  • Parameterized Trigger Plugin
Skip to end of metadata
Go to start of metadata

Plugin Information

View Parameterized Trigger on the plugin site for more information.

Older versions of this plugin may not be safe to use. Please review the following warnings before using an older version:

This plugin lets you trigger new builds when your build has completed, with various ways of specifying parameters for the new build.
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 Master.

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.

*** YOU MUST DEFINE THE PARAMETER IN DOWNSTREAM JOBS VIA  "This project is parameterized". For example, if job1 passes ABC=123 to job2 then in job2 mark the job as "This project is parameterized" and "Add Parameter" named "ABC". ***

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_<project name>="Last build number triggered"
    from version 2.17 onwards
  • 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}.

Please submit bugs and feature requests to the issue tracker and not (only) in the comments.

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 (<yourserver:port>/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 buildstep 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

  • Page:
    Git Plugin — This plugin allows use of Git as a build SCM, including repository browsers for several providers. A recent Git runtime is required (1.7.9 minimum, 1.8.x recommended). Interaction with the Git runtime is performed by the use of the Git Client Plugin, which is only tested on official git client. Use exotic installations at your own risk.
  • Page:
    NodeLabel Parameter Plugin — This plugin adds two new parameter types to job configuration - node and label, this allows to dynamically select the node where a job/project should be executed.

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 behavir 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 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 taken as a designated behavior.
    • As those failures are ones designed by parameter definitions. For example, the choice parameter is designed not to accept unexpected values.
    • You will face same problem when you triggered those builds with Jenkins CLI or Remote access API.
  • It is recommended to fix your project configuration to have parameter definitions not fail.
  • As backward compatibility, you can make it work without fix by setting Java system property hudson.plugins.parameterizedtrigger.ProjectSpecificParametersActionFactory.compatibility_mode to true.
    • It can be done with launching Jenkins as followings:

      java -Dhudson.plugins.parameterizedtrigger.ProjectSpecificParametersActionFactory.compatibility_mode=true -jar jenkins.war
      
    • In RedHat Linux systems, you can modify /etc/sysconfig/jenkins as following:

      -JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true"
      +JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Dhudson.plugins.parameterizedtrigger.ProjectSpecificParametersActionFactory.compatibility_mode=true"
      
    • In Debian Linux systems, you can modify /etc/defaults/jenkins as following:

      -JAVA_ARGS="-Djava.awt.headless=true"  # Allow graphs etc. to work even when an X server is present
      +JAVA_ARGS="-Djava.awt.headless=true -Dhudson.plugins.parameterizedtrigger.ProjectSpecificParametersActionFactory.compatibility_mode=true"  # Allow graphs etc. to work even when an X server is present
      
    • In Windows system, you can modify jenkins.xml placed in the installed folder.

      -<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=8080</arguments>
      +<arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Dhudson.plugins.parameterizedtrigger.ProjectSpecificParametersActionFactory.compatibility_mode=true -jar "%BASE%\jenkins.war" --httpPort=8080</arguments>
      

Changelog

2.35.1 (July 12, 2017)

  • Prevent NullPointerException when Parameterized Trigger starts multiple builds and rejects some of them due to the missing Job/Build permission (JENKINS-45471)

2.35 (July 10, 2017)

2.34 (Jun 19, 2017)

  • Update Jenkins core minimal requirement to 1.642.3
  • Trigger config: Handle missing ancestor job when selecting Downstream Projects in non-job items (JENKINS-32527)

2.33  (Feb 26, 2017)

  • Allow passing current build parameters to the projects being triggered via Parameterized Post-Build Trigger (PR #99)
  • Allow setting downstream projects to be triggered from child projects (PR #106)
  • Prevent error when triggering a list of project with a trailing comma (PR #111)
  • Prevent NullPointerException in the case of race condition with project enabling/disabling (PR #110)
  • Ensure that FileParameter file is closed after its reading when constructing parameters (PR #102)

2.32 (Jul 26, 2016)

  • Log a message instead of throwing a NullPointerException when not being able to load a build's workspace (PR #105)

2.31 (Dec 16, 2015)

2.30 (Dec 16, 2015)

  • Fix the sub project list visualization if a user has Item.DISCOVER without Item.READ (JENKINS-31727)
  • Minor fixes and improvements (PR #91)

2.29 (Sep 10, 2015)

2.28 (Mar 7, 2015)

  • Support firing downstream workflow jobs via trigger (issue #26050)

2.27 (Mar 7, 2015)

  • Allow using non-default artifact manager for properties file (issue #28980)

2.26 (Mar 7, 2015)

  • Trim file names in property file lists
  • Updated the version of depending subversion-plugin to 1.38 with svnkit-1.3.6-jenkins-2 that supports TLS. (JENKINS-25772)
  • Add FAILURE_OR_BETTER Trigger Threshold. (JENKINS-26029)
  • Rely on archived artifacts to trigger (parameterized) build fallback to workspace for backward compatibility. (JENKINS-25192)
  • Added export of triggered builds and jobs to XML/JSON API. (JENKINS-26031)
  • Updated required core version to 1.580.1 - the plugin requires now Java 6 (the same as Jenkins Core itself)

2.25 (Jun 1, 2014)

  • FIXED: useMatrixChild in FileBuildParameters cannot be configured at all. (JENKINS-22705)
  • Support absolute paths in "Parameters from properties file". (JENKINS-23084)
  • Allow using parameter files even if no workspace exists. (JENKINS-22229)
  • Output more informative logs when failing converting parameter values in compatibility mode. (JENKINS-22281)
  • FIXED: Checking project names in configuration page works wrong with Cloudbees Template plugin. (JENKINS-22856)

2.24 (Mar 16, 2014)

2.23 (Mar 09, 2014)

  • Now attempts to convert parameter strings to the type defined in the project
    • When the parameter definition is subclass of SimpleParameterDefinition, Parameterized Trigger plugin tries to create a parameter value by calling SimpleParameterDefinition#createValue, which is used when triggering builds via CLI.
  • Avoid NPE by checking the getLastSuccessfulBuild() for null before calling resolveProject() (JENKINS-20932)
  • Supports property files with non-ascii characters. This feature only works properly in Java 1.6, but Java 1.5 is still supported. (JENKINS-19990, JENKINS-20651)
  • Matrix project support for "Parameters from properties file". (JENKINS-21013)
  • Added license notice (MIT) (JENKINS-21270)

2.22 (Dec 13, 2013)

  • Fixed projects.size to projects.size() in groovy script. This caused exception with IBM Java 6. (JENKINS-20719)
  • expand variable in project names looking for unresolved names
  • Triggered subprojects displayed in build status pages now preserves the triggered order.

2.21 (Oct 06, 2013)

  • Supported hierarchical job model (cloudbees folders)
  • Avoids NPE when used as a build step and the triggered job is deleted or renamed (JENKINS-19793)

2.20 (Aug 26, 2013)

2.19 (Aug 11, 2013)

  • Bugfix: Check existence of all subproject(s) before launching
  • List configured and triggered subproject from project view (subprojects are grouped into static, dynamic and unresolved)
  • set upstream builds to original builds of promotions (JENKINS-17751)

2.18 (Jun 2, 2013)

  • Added a new parameter factory type that takes multiple BLOB files and trigger one build each.

2.17 (Feb 26, 2013)

Fixed Issues

  • Parameterized trigger from a multi-configuration project triggers downstream jobs twice (JENKINS-11669)
  • Allow speciying Git SHA1 commit id for next build(s) as Predefined parameter (JENKINS-13852)
  • Counter/File Parameter Factories now can prevent triggering, skip adding parameteers or fail the build if errors occur. (JENKINS-13872)
  • A parameterized buildstep in a matrix project causes IllegalArgumentException (JENKINS-14278)
  • Unusable environment variable TRIGGERED_BUILD_NUMBER_jobname (JENKINS-14545)
  • It's not possible to specify multiple property files in parametrised trigger (JENKINS-15834)
  • Boolean parameter becomes string (JENKINS-15920)
  • Define impllicit parameter: "build them on the same node" (JENKINS-16334)

Note

Environment parameter names have changed from previous version, due to fix for (JENKINS-14545) when using as a build step.
Project names are now alphanumeric only and all other consecutive chars replaced with _

2.16 (Oct 09, 2012)

  • Error validating project name in form (JENKINS-15130)
  • clarify error when no parameter set and triggerWithNoParameter unchecked (unfiled)

2.15 (May 23, 2012)

  • Allow each parameter type to be selected only once (requires Jenkins core version 1.463!). (JENKINS-8916)
  • Fix triggering projects based on variables (JENKINS-13875)

2.14 (Apr 27, 2012)

  • Fixed infinite loop, when "Block until the triggered projects finish their builds" option is used and triggered projects are disabled. (JENKINS-12923)
  • Added a new parameter definition in the trigger that lets the upstream controls which subset of the downstream matrix job to build.

2.13 (Feb 9, 2012)

  • Builds triggered as build steps will now appear as downstream builds. (JENKINS-11082, JENKINS-9263, JENKINS-5184)
  • Info on builds kicked off as blocking build steps exposed. (JENKINS-11345)
  • When multiple builds are launched as blocking build steps, all should be listed as "waiting to complete", and should be listed in launched order. (JENKINS-11116, JENKINS-11117)
  • Fixed a compatibility with hierachical jobs (such as the CloudBees folder plugin.)
  • Added a mechanism to repeatedly invoke jobs for each file that matches GLOB (pull #11)

2.12 (Oct 30, 2011)

  • Added a mechanism to repeatedly invoke the same project with different set of parameters.
  • Improved the default value of the blocking configuration.
  • Added hyperlinks to console output

2.11 (Aug 6, 2011)

2.10 (Jul 10, 2011)

  • Implemented JENKINS-10028: Textbox for downstream projects should be validated as with the "Build other projects" text box.
  • Implemented JENKINS-8788: When renaming a job, the parameterized trigger should reflect the new name if the job appears as a parameterized triggered job.

2.9 (Jul 10, 2011)

  • Fix subversion plugin dependency.
  • Multiple triggers between the same upstream/downstream project combo will now work, though this will also depend on Jenkins core 1.414. (JENKINS-8985)
  • Implemented JENKINS-9217: Added a new option to not run further build steps if triggered builds fail or are unstable
  • Implemented JENKINS-9391: Allow triggering projects based on variables

2.8 (Mar 27, 2011)

  • Prevent IndexOutOfBoundsException, when no projects are specified.
  • Added new "Trigger build without parameters" option for post-action trigger builds.

2.7 (Mar 1, 2011)

  • Rerelease 2.6 to properly set required Jenkins version.

2.6 (Feb 17, 2011)

  • Improved the progress report to show what jobs are being executed when used as a builder.
  • Fixed NPE when the child build is called concurrently by other jobs.

2.5 (Feb 12, 2011)

  • Added a mechanism to call other builds synchronously and map their results.

2.4 (Jul 29, 2010)

  • Fix passing of parameters when a maven project is the upstream job. (JENKINS-6141)
  • Add support for multiconfiguration(matrix) projects. (JENKINS-5687)
  • Fix variable expansion in "predefined parameters" so backslashes in variable values are not lost. Add help text about backslash handling. (JENKINS-6004)
  • File parameters are currently not reusable, so omit these when "current build parameters" is selected. (JENKINS-6777)
  • Update trigger settings when other jobs are renamed or deleted. (JENKINS-6483)
  • Add an "always trigger" option. (JENKINS-6656)

2.3 (Jan 16, 2010)

  • NOTE: This release is built against Jenkins 1.341 but works with Jenkins 1.319 or higher.
  • Implement Jenkins API so connected jobs show in Upstream/Downstream Projects list on job pages with Jenkins 1.341 or higher. (JENKINS-5184)
  • Merge together parameter lists from multiple sources to avoid multiple Parameters links on build pages (JENKINS-5143) and failure to pass some parameters further along the downstream chain (JENKINS-4587).

2.2 (Jan 11, 2010)

2.1 (Jan 9, 2010)

  • Implement Jenkins API so connected jobs show in Upstream/Downstream Projects list on job pages. (JENKINS-5184)

2.0 (Aug 10, 2009)

Major refactoring. Now supports any combination of projects to build, result condition and set of parameter sources.

Should be backward compatible for configuration, except the 'batch condition' which was removed.

1.6 (Jul 18, 2009)

  • Removed downstream projects parameters duplication.

1.5 (Jul 5, 2009)

  • Added batch condition: a batch/shell script can be used to decide if project[s] built should be triggered.
  • If downstream project parameters values are not specified explicitly their default values are used now (empty values was used in previous versions).

1.4 (Jun 11, 2009)

  • Environment variables (including current build parameters) can now be used in the downstream build parameters and in parameters file name.

1.3 (Feb 28, 2009)

  • Trigger another build when the current is unstable

1.2 (Feb 27, 2009)

  • Fixes incompatiblity with Jenkins 1.285. Jenkins 1.286 is a minimum requirement for this version.

1.0, 1.1 (Feb 9, 2009)

  • Initial release

type priority key summary

Data cannot be retrieved due to an unexpected error.

View these issues in JIRA

87 Comments

  1. Is it possible to use current build parameters to form parameters of downstream build?

    For example, to send build number to downstream project one may write:

    SOURCE_BUILD_NUMBER=${BUILD_NUMBER}
    
  2. Unknown User (jstano@gkservices.com)

    How about using the parameters passed by this plugin in an SVN URL?  I know this is possible with a parameter on the job itself, but it doesn't seem to work when the job is invoked by this plugin.

    For example: job 2 has a parameterized SVN URL

        http://hudson_host/repo/tags/${tagNumber}
    

    and job 1 is pulling the 'tagNumber' property from a properties file and invoking job 2 via this plugin.  The parameter does not get resolved, so the build fails.

    1. I've tested this out today with latest versions of Hudson and Parameterized Trigger Plug-in. Everything seems to be working as expected (I've managed to use parameter that have been passed from upstream project in SVN URL). Can you give more details?

  3. Great plugin!

    There is a few things I cannot get working though. Hopefully you can help me (or at least give me a hint on how to continue).

    I'm using the comment-function since someone else maybe can benefit from the answer.

    When I'm using this plugin instead of the default "Build other projects"-functionality, a couple of the standard features stops working or goes missing.

    For instance, the connection between the downstream and upstream job is somewhat "lost". E.g. on the project page, the "Downstream Projects"/"Upstream Projects"-section goes missing. This makes it very hard for the users to find the triggered jobs.

    Even worse, the downstream test results cannot be aggregated between jobs.

    Have I maybe missed some settings/functionality? Is it an implementation decision? Or is it a bug?

    Best regards

    Gustaf

    1. It seems that "Downstream Projects" and "Upstream Projects" sections are built-in ones. It may be possible to add their support to Parameterized Trigger (I'm not sure though), but it's not really an issue.

      Test results aggregation is quite different one. I'll try to do something about it as soon as I get some free time.

      Best regards,
      Maxim

  4. Was there any specific reason for removing batch condition? It was really useful. Can you suggest another way for conditional project building in Hudson?

    1. I absolutely need the batch conditions. The batch conditions are used to make it possible to chain multiple projects together and use the same projects in between. A variable is used to identify which "chain" is used.

      Please, please, please add them back.

      1. Any chance you might reconsider the removal of the batch conditions? Please?

        1. I also really need this feature, there's currently no other way to implement conditional chaining in Hudson.

          1. Yes, this batch conditions is really useful, please consider add it back.

            BTW, any document about how to contribute to the parameter section?

            1. Unknown User (salman__awan@hotmail.com)

              Definitely, Conditionally initiating builds based on parameters is perfect place for this plugin to have.

              Scenario is, one job builds the war, and then it triggers other jobs to run SSH based remote deployment script, thus enabling same war deployment on multiple EC2 instances e.g. test, dev, demo etc. But always every build is not for all environments, so having a Parameter based conditional logic in this Plugin will enable us to deploy only on selected environments.

              Reading through comments, suggested that such functionality 'Batch condition' was previously implemented. Also has an Issue in Jira here , if you want this functionality back too, vote it up.

  5. Unknown User (abelous@hotrmail.com)

    Is it possible to run parameterized build remotely from the script ? I was trying to use "Trigger builds remotely" but I can not find a way to specify parameters in URL

    Also If I have 2 Build triggers, currently they executed in parallel .Can option to control order
    of trigger execution be added to "Trigger when build is " list ?

  6. Unknown User (foldvari)

    It seems, that actual triggering is blocked, if there are no parameters given, e.g. the parameter file is missing. Is this intentional? Can I use it as a kind of conditional triggering? Or It is a bug therefore I cannot rely on it?

  7. Unknown User (max khon)

    For multiconfiguration project the build is triggered for each configuration, unlike "Build other projects" when downstream project is built once for multiconfig project.

    Can this be made either configurable or made to be run once per project, not per configuration?

  8. Unknown User (shimi)

    How can I use the "Subversion revision" in the triggered project?

  9. Unknown User (kvsn4u@gmail.com)

    I have configured 2 jobs A and B, A should call B on success with parameters.

    Using this plugin, i have selected option of "Use properties from file" and supplied a properties file "temp.properties", with key=value pairs, one per line in that file.

    Unfortunately, Job A on success is not triggering Job B throwing an error in the log error file as below:

    <snip>

    INFO: A #1029 main build action completed: SUCCESS
    Dec 21, 2009 10:28:15 AM hudson.model.Executor run
    SEVERE: Executor throw an exception unexpectedly
    java.lang.NoSuchMethodError: java.util.Properties.load(Ljava/io/Reader;)V
        at hudson.plugins.parameterizedtrigger.FileBuildParameters.getAction(FileBuildParameters.java:54)
        at hudson.plugins.parameterizedtrigger.BuildTriggerConfig.perform(BuildTriggerConfig.java:75)
        at hudson.plugins.parameterizedtrigger.BuildTrigger.perform(BuildTrigger.java:49)
        at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
        at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:583)
        at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:564)
        at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:551)
        at hudson.model.Build$RunnerImpl.cleanUp(Build.java:158)
        at hudson.model.Run.run(Run.java:1221)
        at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
        at hudson.model.ResourceController.execute(ResourceController.java:88)
        at hudson.model.Executor.run(Executor.java:122)

    </snip>

    Can some one help me on this.... Its a bit urgent for me.

  10. I use the SVN revision option.  It works very nicely. 

    Is there a way to pass "svn revert" and/or "svn update" options?  I want to do "non-update" checkouts occasionally.

    Thank you.

    1. Unknown User (st3@holometric.de)

      How did you get it working? I kinda stuck with it, Hudson can't check out from my repostitory:

      Checking out https://subversion/path/to/branch @${SVN_REVISION}
      ERROR: Failed to check out https://subversion/path/to/branch @${SVN_REVISION}
      org.tmatesoft.svn.core.SVNException: svn: URL 'https://subversion/path/to/branch%20@$%7BSVN_REVISION%7D' doesn't exist
      

      i've also tried @$SVN_REVISION and @%SVN_REVISION%, but the same error occurred. If I put a number at the place instead, it works.

      1. You are working too hard.  It appears that as long as the master job is set up to pass the built-in subversion revision, the sub-job uses the revision number without you using $ this or % that.  

        1. Unknown User (st3@holometric.de)

          unfortunatly, it doesn't, at least not at my installation. I've already put the problem to the mailing list, but without any answer so far:

          http://n4.nabble.com/Use-same-SVN-Revision-for-alle-downstream-builds-td1746469.html#a1746469

  11. Great plugin! But we are in serious need of support for triggering a build after the flyweight (parent) of a multi-configuration build completes. Currently nothing happens in this scenario.

    thanks!

  12. I've had trouble using variables with periods or underscores in them on Linux jobs called by Windows master jobs.  If I remove those special characters, everything works fine. Also, on Windows, environment variables names are often upper cased for you.  So using exclusively upper case in env var names saves a lot of headaches.

  13. Unknown User (mte@voicetrust.de)

    I would like to use this plugin to build project A, project C and project B in this sequence, but Hudson will build project A, project B and project C (alphabetical order).

    Doing something wrong? Thanks

  14. Unknown User (jl.pinardon)

    It appears that it doesn't work altogether with the Join Plugin.
    Once the Parameterized Trigger plugin is configured to launch some jobs, passing them some parameters (and that is the important point !), the it seems that the Join Plugin doesn't fire at all. Just like if the jobs declared within the Parameterized Trigger section were not understood as downstream projects to wait for.
    Installed versions are "Join plugin" (version 1.8 ) and "Hudson Parameterized Trigger plugin" (version 2.3) on Hudson 1.364.
    ...
    But it appears that the Join Plugin finally correctly fires after I've made too many trials to be able to understand what has finally made it works !
    Probably not a trivial bug....

  15. Unknown User (jl.pinardon)

    I have a top job which launch a downstream job using the parameterized trigger plugin. Some Predefined Parameters are set.
    The downstream job correctly get the parameters. OK. But it modifies it and then launch some jobs passing them its "Current Build Parameters".
    I thought this will pass the modified values. But it does not. The original values are passed.
    So, if it is not a bug but a misunderstanding, how can I manage to pass a parameter which can change within a job and be seen with its new value in the downstream ?
    Thanks for your help.

    1. Write the new parameters in a file. And use file parameters when triggering the next parametrized job.

      The reason is, that a parameter change will not survive the build step. So if you have two build steps and change the parameter in the first step, you can't use the new value in the next step. Remember, The parameter is just exposed as a simple environment variable, which usually can not be persisted in a way, that it survives the current shell session. You have the same issue when changing or creating new environment variables. They also don't survive the build step.

  16. Unknown User (ourkov)

    Are there detailed instructions for using this plugin anywhere?  I have a project that gets built on three different platforms and am trying to use this plugin to ensure that my scheduled builds all use the same revision of the source code.  I have a master job that is configured to "Trigger parameterized build on other projects" (which are the two downstream jobs) with the only parameter being "Subversion revision".

    The two downstream jobs are correctly triggered, but if a checkin occurs while the master job is running, the downstream jobs still check out from HEAD instead of the revision that the master job checked out.

    Attempting to use the SVN_REVISION environment variable in the SVN URL of the downstream jobs results in checkout failure (Hudson doesn't resolve $SVN_REVISION).

    From what I've read on this page, it seems like just adding the "Subversion revision" parameter should guarantee that the triggered builds check out the same revision as the master job but my triggered builds continue to check out HEAD.  I'd really like to know what I'm doing wrong.  I can hack my build scripts to get SVN_REVISION from the enviornment and re-check out the specified revision but that seems like a lot of overhead since these projects are large! 

    Any advice or docs would be much appreciated.  Thanks in advance!  :)

  17. Unknown User (jducrey)

    Hi,

    i have a simple question :

    Is it possible to launch parametrized trigger with a parameter ?

    for example instead of building target1 is there a way to build $target1 ?

    I have several jobs that deploy ears and they all call the purge job if they failed and i'd like that the purge job call back the failed job when the purge is done. And of course i want only one purge job.

  18. Unknown User (prash)

    I am trying to use parameter trigger plugin, however facing some issues. In the upstream job we have a shell script which creates some dynamic variables and these have to be passed to the downstream job. How could we do this. I have tried exporting of the variables and putting them to a file to be used by "parameters from properties file", however am not getting any variables values into the parameter properties file. Please help.

    The setup looks like below in hudson:

    Build
    Execute Shell:
    /home/user/myscript.sh
    echo "var1=$value1" >> parampropertiesfile
    echo "var2=$value2" >> parampropertiesfile

    Where the $value1,2 etc are exported in the myscript.sh

    There seems to be an issue with the exported values from the shell script.

  19. I have tried to trigger a job to run 3 time with 3 lots of parameters at the end of the run of my main job, but only the first of these three jobs is being triggered.
    Is this behavior correct ?

  20. Unknown User (cthayer@sensorlogic.com)

    Is there a way to disable a downstream parameterized job programmatically? We have two hudson jobs that are linked, if job A is successful the downstream job B is invoked. This works fine as designed. However, there are times when we want to run job A but NOT have it invoke job B (whether job A is successful or not). I tried using a variable for the downstream job name and, at first, it looked like that might work (i.e., when an empty string was passed as the downstream job name it, obviously, wasn't called and job A produced no errors). But when I passed the downstream job name in the variable the primary job still did not see downstream job to invoke.

    Adding the ability to enable/disable a project's downstream job(s) programmatically would be a very useful feature for us.

    1. Hi Craig,

      We're currently experimenting with this, and the approach we've tried is to have three build jobs, call them A, B, C. What we want to achieve is to have job A accept parameters, and do nothing; job B verify the parameter (version); and job C perform the build.

      Job B will be called by many other builds which also need to verify the version parameter.

      First, naming them "A", "B", and "C" is essential, as they are built in alphabetical order regardless of how they're specified in the text field (keep that in mind for "real" names, in which you could include numbers for proper sorting; for instance we started this effort with "BAT-Entry", "BAT-Version", and "BAT-Main" (BAT=Build Automation Testing), but it called BAT-Main before BAT-Version, so we then renamed them to BAT-1-Entry, BAT-2-Version, and BAT-3-Main).

      Second, success/failure of the downstream job(s) is "ignored" – BAT-1-Entry succeeds, then calls BAT-2-Version, and whether that succeeds OR fails, it invokes BAT-3-Main. Not what we want; we want that when BAT-2-Version fails, it does NOT invoke BAT-3-Main, and also it causes BAT-1-Entry to fail (so it's somewhat of an "upstream" build, but we want it to run after giving the parameters to the BAT-1-Entry build).

      Third, success/failure of the downstream job(s) are not "bubbled up" to the entry job (mentioned in the above paragraph).

      Fourth, it would be really nice if the console output for BAT-1-Entry was to include the console output of both BAT-2-Version and (if it ran) BAT-3-Main.

      So then the next thing I tried was to add a parameter named "job" to BAT-1-Entry, change it to only invoke BAT-2-Version, and then have BAT-2-Version invoke a parameterized trigger build (on success), specifying "$job" as the name of the job to build. Unfortunately, this never runs BAT-3-Main, regardless of if it succeeds or fails (meaning, the Parameterized Trigger Plugin does not seem to expand parameters in the job name).

      Without the ability to have the version check job run a variably-named third job, we would need to create one version job per main job (see my second paragraph, above). This is slightly better than currently, where we have to "copy" the version check script from one TFS location to another, so that it is included in that build's source code sync, and invoke it from that build's Hudson Configuration as the initial step (and, when modified, "copy" to all the other locations...) – but it would be much better if this worked more like WTT.

      So, I am currently at a loss as to how to achieve our goal using this plugin. Is it possible? If not, does anyone know of other plugins that will satisfy our needs?

      1. Hi Ken,

        same solution for you as well. As the last build step, use the remote API to invoke the downstream job. With the API you can script (program) the logic that you need.

        If you want an enhancement I suggest, that you create an issue for it in jira.

        Peter

    2. Hi Craig,

      This mechanism is not implemented at all in Hudson. But there is help. You can use the remote API to trigger a build. If your Hudson is secured you need to provide username and password when invoking a build.

      Peter

  21. Unknown User (amir k)

    It seems that the plug-in is broken in the latest Hudson version, 1.394. The downstream jobs are not triggered. Anyone else seen that?

    Thanks,

    Amir

    1. Someone else mentioned this in IRC, but when I tried it I couldn't find any problems (tried "on success" and "on failed" triggers).

  22. Unknown User (amir k)

    I upgraded my Hudson installation to the latest (1.395) and the plug-in seem to work just fine. I guess that's the price one pays being on the bleeding edge(wink)

  23. Unknown User (jl.pinardon)

    Hello,

    When configuring some downstreams jobs with parameters to pass for all but one job, it appears that the job without parameter is not launched, while all others are correctly launched.
    Is it the normal and awaited behaviour ?

    Thanks for your help.
    J-L

  24. I want to trigger two instances of the same downstream job following successful completion of the first job, but with different predefined parameters (essentially I want to trigger a deployment to two different environments).

    To do this I have defined two Build Triggers:

    Project to build: RELEASE_JOB
    Trigger when build is: Stable
    Predefined parameters: ENV=test

    Project to build: RELEASE_JOB
    Trigger when build is: Stable
    Predefined parameters: ENV=uat

    However, at the moment only the first trigger gets fired (ie ENV=test); the second trigger appears to be ignored.

    Is is possible to do this?

  25. At the moment one can trigger several projects by providing "a comma separated list of projects to build". I would like to ask whether it is possible to use wildcard characters like *Test to trigger all tests, e.g. FirstTest SecondTest, ThirdTest etc.?

  26. Unknown User (nissancedric@netscape.net)

    With the new 2.9 version how do I trigger the project using a variable?

    1. Just to clarify, the description of JENKINS-9391 says: "The goal here is for the Projects to build field to support variables."

      You could have a parameterized build which accepts a project name as input and stores it in a variable (for example $PROJECT_TO_TRIGGER). This variable can then be used in the "projects to build" field of a parameterized trigger.

      HTH

      1. I've tried this, in the most simple scenario possible, but I can't get it to work. I have my steps documented in detail right here. Could someone please give me some feedback as to what I'm doing wrong?

  27. When I "Pass through Git Commit that was built", is the GIT_COMMIT environment variable then guaranteed to be the same git commit SHA-1 checksum that was checked out in the upstream build?

    Thanks!
    -Adam

  28. User permissions are not kept in a triggered project, which can run as if triggered by a simple "authenticated user".

    Example: the current user has permissions to fully inspect project A and B, while a simple authenticated user cannot see any. The current user launches A which can trigger B (user permissions allow this). Project B wants to copy some well defined files from the caller, but it can't because it is run without keeping the user's permissions, so the caller project is not found.

    Is this an upstream problem?

    Regards
      Max

  29. How is it possible to let the plugin pass parameters to all automatically detected downstream jobs when using a Maven job?

    Downstream jobs are automatically detected when using Maven jobs with the setting "Build whenever a SNAPSHOT dependency is built" enabled. 
    A such that I am not able to select a downstream job as it's detected automatically by the Maven job.

    Thanks, Ed

  30. I have issue (https://issues.jenkins-ci.org/browse/JENKINS-12113):

    Maven - java.io.IOException: error=2, No such file or directory if in SVN configuration parameters used in Local module directory section.
    

    Parameter does not resolved neither for Maven nor for Ant if we specify parameter in Local module directory in Source Code Management section.

    Please assist.

    Thanks!

    1. I am not sure why u ask this question here. The ticket confirmed, that it is an Maven plugin issue (I suspect the same for ant). Please be more specific with what you want assistance with.

      1. Hi Peter,

        I'm asking this question because I suspect that Parameterized Trigger Plugin could be the root (or compatibility of this plugin with Maven and Ant Plugins). I suppose you should know better how parameters resolving is working (I'm not developer) therefore I've asked for your advice. I've replied your comment in the ticket.

        Thanks for your help in advance!

  31. For the param 'types', would it be possible to add a 'datetime' so that when i run a build with params i can select from a javascript calendar and/or clock instead of typing in a perfectly formatted timestamp?

    That would be really cool.

  32. Why aren't the parameter factories available in the post-build instance of this plugin?

    edit: just found https://issues.jenkins-ci.org/browse/JENKINS-13966

  33. Hi there,

    I was wondering if anyone can help me with a problem.

    I'm running Jenkins 1.475 and I just installed this plugin (version 2.15). I am trying to trigger another job as a build step. I do 'Add build step' > 'Tigger/call builds on other projects'. First of all, there is some weird behaviour because the first trigger I create does not allow me to see anything. If I delete it and create another one (in exactly the same way) then I can work with it. But the worst is that after setting up this trigger I get the following message when trying to save the new configuration:

    Status Code: 500
    Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder from {"configs":{"block":true,"buildStepFailureThreshold":"FAILURE","failureThreshold":"FAILURE","projects":"XXXXX","unstableThreshold":"UNSTABLE"},"kind":"hudson.plugins.parameterizedtrigger.TriggerBuilder","stapler-class":"hudson.plugins.parameterizedtrigger.TriggerBuilder"}
    Stacktrace:
    
    javax.servlet.ServletException: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder from {"configs":{"block":true,"buildStepFailureThreshold":"FAILURE","failureThreshold":"FAILURE","projects":"XXXXX","unstableThreshold":"UNSTABLE"},"kind":"hudson.plugins.parameterizedtrigger.TriggerBuilder","stapler-class":"hudson.plugins.parameterizedtrigger.TriggerBuilder"}
    	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:616)
    	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
    	at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
    	at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
    	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
    	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
    	at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
    	at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
    	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
    	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
    	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488)
    	at org.kohsuke.stapler.Stapler.service(Stapler.java:162)
    	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    	at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
    	at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    	at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
    	at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
    	at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    	at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50)
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    	at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
    	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
    	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
    	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
    	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
    	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
    	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
    	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
    	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
    	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
    	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:300)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    	at java.lang.Thread.run(Thread.java:619)
    Caused by: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder from {"configs":{"block":true,"buildStepFailureThreshold":"FAILURE","failureThreshold":"FAILURE","projects":"XXXXX","unstableThreshold":"UNSTABLE"},"kind":"hudson.plugins.parameterizedtrigger.TriggerBuilder","stapler-class":"hudson.plugins.parameterizedtrigger.TriggerBuilder"}
    	at hudson.model.Descriptor.newInstance(Descriptor.java:575)
    	at hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:912)
    	at hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:899)
    	at hudson.util.DescribableList.rebuildHetero(DescribableList.java:203)
    	at hudson.model.Project.submit(Project.java:202)
    	at hudson.model.Job.doConfigSubmit(Job.java:990)
    	at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:699)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    	at java.lang.reflect.Method.invoke(Method.java:597)
    	at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288)
    	at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151)
    	at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90)
    	at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111)
    	at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
    	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
    	... 46 more
    Caused by: java.lang.IllegalArgumentException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder from {"configs":{"block":true,"buildStepFailureThreshold":"FAILURE","failureThreshold":"FAILURE","projects":"XXXXX","unstableThreshold":"UNSTABLE"},"kind":"hudson.plugins.parameterizedtrigger.TriggerBuilder","stapler-class":"hudson.plugins.parameterizedtrigger.TriggerBuilder"}
    	at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:633)
    	at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:377)
    	at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:373)
    	at hudson.model.Descriptor.newInstance(Descriptor.java:566)
    	... 62 more
    Caused by: java.lang.IllegalArgumentException: Failed to convert the configs parameter of the constructor public hudson.plugins.parameterizedtrigger.TriggerBuilder(java.util.List)
    	at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:627)
    	... 65 more
    Caused by: java.lang.IllegalArgumentException: Failed to instantiate class hudson.plugins.parameterizedtrigger.BlockableBuildTriggerConfig from {"block":true,"buildStepFailureThreshold":"FAILURE","failureThreshold":"FAILURE","projects":"XXXXX","unstableThreshold":"UNSTABLE"}
    	at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:633)
    	at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:669)
    	at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:377)
    	at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:625)
    	... 65 more
    Caused by: java.lang.IllegalArgumentException: Failed to convert the block parameter of the constructor public hudson.plugins.parameterizedtrigger.BlockableBuildTriggerConfig(java.lang.String,hudson.plugins.parameterizedtrigger.BlockingBehaviour,java.util.List,java.util.List)
    	at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:627)
    	... 68 more
    Caused by: java.lang.IllegalArgumentException: Unable to convert to class hudson.plugins.parameterizedtrigger.BlockingBehaviour
    	at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:688)
    	at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:377)
    	at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:625)
    	... 68 more
    
    
    Generated by Stapler at Thu Aug 16 17:45:57 CEST 2012
    

    Any thoughts on this? Is it a bug?

    1. Nevermind, I should have googled better. For those interested, this is bug 14495 and it has been fixed in version 1.477.

  34. I'm using a matrix configuration job to trigger one other build job for each set of parameters. However it seems that the parameters from the config matrix (other parameters are fine) are not passed over to the builds I trigger (even though I enabled the "add parameters> current build parameters" option).

    This may be akin to JENKINS-14251 and JENKINS-11577.

  35. hi, this plugin is very usefull!

    but I want to trigger different job according by cosole log.

    for example:

    if console log include 'need build project1', the parameterized trigger job trigger project1 with current build parameters.

    if console log include 'need build project2', the parameterized trigger job trigger project2 with current build parameters.

    'Post build task' (https://wiki.jenkins-ci.org/display/JENKINS/Post+build+task) can filter the console log, but cannot trigger new job with parametes.

    Did you have any idea?

    1. Use the Conditional Build step plugin (https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin) and add the trigger as the last Build step to your job. If you don't block your build when triggering the other project it will be like a post build step.

      1. hi,

        thanks for your quick reply!!

        I just try with your suggestioin, maybe it's a workround, but this plugin need cofigure all downstream job, and all downstream job will be triggered but just run nothing every times.

        If the Parameterized+Trigger+Plugin can integrate with Post+build+task_Plugin or Text+Finder+plugin, this will be a professional solution.

        Thank you again!

  36. Howdi folks,

    i am trying to schedule build, but need to pass parameters to complete them. Jenkins provide option of scheduling  builds but can i use this plugin to pass parameters. for example target server, everytime build is triggered target server need to selected from drop down. any ideas.

    Thanks

    -Rose

  37.  I can't upload about 4G large file to jenkins by file parameterized,when i upload 4G large file ,the web is reset directly,but 2G large file is ok.Could you help me?

  38. We are experiencing some strange behaviour since the last update: downstream jobs are started even before the triggering job is finished. We have a downstream job that copies files from the lastStable build. However, the downstream job is started and starts copying files before the lastStableBuild link is updated (easily visible by looking at the timestamps in the file system) and will them fail when the link suddenly changes in between. The downstream job even has the flag "block as long as upstream job is running" set.

  39. Has anyone experienced the problem where the upstream project loses track of the downstream projects that it spawns? We have a upstream job that spawns approximately 20 downstream jobs. Occasionally we will run into the situation where the downstream jobs complete but the upstream job shows that its still waiting for them to complete. We've been unable to trace the source of the problem. 

  40. How can I start job like

    QA_SSM_AUTOCONFIG_StartTests/slave=master,ssmEnv=stl-alms-tst7?

    there is a comma in job params and I can't drop one of params.

  41. Hi, 

    I encountered issue when attempting to access parameterized triggered jobs information via groovy script. After upgrading Jenkins version to 1.596, I found we can no longer use "getDownstreamProjects()" function of "Item" object to retrieve the sub job information defined in parameterized trigger plugin within 'Build' phase(which works fine under v1.532). Only those jobs defined the 'Post-build' phase can be retrieved from this API.

    Could you please suggest is there any way we can get the triggered job information?

    Thanks!

  42. Is there a way to have it evaluate an expression?  I want to do an assignment of a build parameter, based upon other parameters. i.e. Paramater=53+(${Job_Parameter}*1000)

    when I do this, and I look at the parameter in the job it is set for, I see 53+(125*1000).  What I want to see is 125053.

    Any ideas?

  43. I find that this plugin doesn't fire the other job when run inside a release phase of the first job and set to run only on "stable". But there is absolutely nothing in the console logs to explain why.

    Could you look at adding some logging to explain why a particular job is or isn't triggered by this plugin?

  44. Hi, can we add another build trigger: "Back to normal" ?

    Failure -> Pass (normal) will trigger this. Thx

  45. How can I trigger the parameterized build only on success using the option "Trigger/call builds on other projects"?

  46. After a recent upgrade of Jenkins and all plugins my downstream projects started not receiving the parameters from the upstream IF the parameter itself was not listed in that sub project. Parameters that are explicitly mentioned in the sub project were fine, those parameters were still being received.  I fixed this by going through ~80 projects and adding in a new string parameter w/ a matching name, which previously was merely inherited only. Did anything change that might impact this?  Is there a way to make a parameter "hidden" from the build project menu itself--It's not really a dealbreaker but just curious.

  47. Hi,

    I am trying to use this plugin with "Predefined Parameters" in the Build Triggers section. But, the parameter cannot use in the triggered job. I tried to print the parameter in shell >>> echo $PORTALNAME;        But it shows only echo.

    Building in workspace /var/lib/jenkins/workspace/TestBuildTestBuild $ /bin/sh -xe /tmp/hudson4158340164919812329.sh
    + echo

    Finished: SUCCESS

  48. This plugin-in is broken.

    Default parameter values are ignored when *some* parameters are provided.

  49. I have weird issue - from time to time my Jenkins freezes, and it seems that it happens on  Parameterized Trigger Plugin step: my upstream build is successfully finished, but 3 downstream jobs aren't starting. I couldn't see something relevant in the logs.
    Any ideas how I can debug this issue?

    thank you,

    Vitaly

  50. This plugin stopped working for me after I upgraded past 1.616.  I have tried 1.656.2 and 2.26 with no luck. Here is my setup.

    Make Docs i20

    • Parameter called PROJ with the value of i20
    • Only build step is Trigger/call builds on other projects (Make Docs Project)
      • using Current build parameters

    Make Docs Project

    • Multi-configuration job
    • User-defined Axis called TYPE (with 5 entries)
    • One build step
      • echo %PROJ%
      • echo %TYPE%

    With 1.616 each of the 5 Make Docs Project jobs will correctly spit out the value of PROJ and TYPE.  At least starting with 1.656, PROJ is empty.  Even with the downstream job is not multi-configuration it still doesn't work.  Did I miss something with a Jenkins version change?  Thankfully I only just discovered this plugin so I'm not dependent on it, but it sure would be useful.  Thanks!

  51. A bit suprised that Post-Build parameterized build triggers can't block the job. Is this something in the works, or not implemented for a reason?

  52. For everyone where this suddenly stopped working, check this Security Advisory

    Basically, Jenkins doesn't forward parameters anymore if they are not defined in the downstream project.

    In your tomcat log, you'll see something like:

    Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach

    Your two options are to:

    1. Add that java property when starting jenkins
    2. Add the parameter to the downstream job
  53. *Background: *We have a number of Jenkins top-level jobs that uses (and shares) other jobs as sort-of subroutines.
    To control the overall flow we use the Jenkins Parameterized Trigger Plugin
    The top-level jobs then gather test reports, build reports etc. from the sub-builds and conveniently publishes them in one go. It's working really well.

    Problem at hand: Each of the top-level jobs are started with a number of parameters, and only a selection of these are passed on to the sub-jobs.
    For some sub-jobs, the parameters are the same as they were some time ago, when the sub-job was last called from this top-level job, but our top-level script isn't aware of this.
    In essence, we waste build time, building the sub-job again with the same parameters.

    In a perfect world the Parameterized Trigger Plugin. would have an option like 

    • Do not rebuild job if identical parameters (and configuration unchanged).

    which would perform the following steps:

    1. Compare the build-parameters of all kept builds of the given job, to the current parameters.
    2. If the job-configuration is unchanged since the found job was build, setup environmental variable to point to the old job that was found above.
    3. If job not found or the job-configuration has been changed since the found job was build, perform the build as usual.

    Unfortunately it does not seem to exist, and I can't find an alternative plugin that provides the functionality I seek.  (Added as feature request JENKINS-42751: Add option to not build already build job.)

    As a workaround, Groovy to the rescue? This is where I guess the Scriptler Plugin and a Groovy Script would come in handy, as it would allow me to perform the check in the sub-job, and then set an environment variable that I can use in the Conditional BuildStep Plugin to either perform the build as usual, or skip the build and setup the build environmental variables using the EnvInject Plugin.

    But: I'm new to Groovy, and to JAVA for that matter. I have lots of other (assembly, C and scripts) programming experience, though. I've searched for example scripts all over, but haven't found anything remotely similar to what I want to do here. Any hints on how to perform this, including alternative takes on the functionality, would be highly appreciated!

  54. Envirment:
    jdk version is 1.8
    jenkins version is 2.60.1
    parameterized trigger plugin version is 2.351

    Problem:
    When i pass parameters from upstreambuild,then predefined parameters cannot pass to downstreambuild,and cannot find error in log.ccccThe build.xml of downstreambuild has <hudson.module.ParametersAction>,and can find then parameters pass from the upstream,but cannot find in <org.jenkinsci.plugins.buildenvironment.data.EnvVarsData> The build.xml of downstreambuild as follow:

    <?xml version='1.0' encoding='cUTF-8'?>
    <build>
    <actions>
    <hudson.model.ParametersAction>
    <safeParameters class="sorted-set"/>
    <parameters class="java.util.Arrays$ArrayList">
    <a class="hudson.model.ParameterValue-array">
    <hudson.model.StringParameterValue>
    <name>LICHEE_BUILD_NUMBER</name>
    <value>2</value>
    </hudson.model.StringParameterValue>
    </a>
    </parameters>
    <parameterDefinitionNames class="empty-list"/>
    </hudson.model.ParametersAction>
    <hudson.model.CauseAction>
    <causeBag class="linked-hash-map">
    <entry>
    <hudson.model.Cause_-UpstreamCause>
    <upstreamProject>test1</upstreamProject>
    <upstreamUrl>job/test1/</upstreamUrl>
    <upstreamBuild>2</upstreamBuild>
    <upstreamCauses>
    <hudson.model.Cause_-UserIdCause>
    <userId>admin</userId>
    </hudson.model.Cause_-UserIdCause>
    </upstreamCauses>
    </hudson.model.Cause_-UpstreamCause>
    <int>1</int>
    </entry>
    </causeBag>
    </hudson.model.CauseAction>
    <org.jvnet.hudson.plugins.DownstreamBuildViewAction plugin="downstream-buildview@1.9"/>
    <org.jenkinsci.plugins.envinject.EnvInjectPluginAction plugin="envinject@2.1.3"/>
    <org.jenkinsci.plugins.buildenvironment.actions.BuildEnvironmentBuildAction plugin="build-environment@1.6">
    <build class="build" reference="../../.."/>
    <build1 class="build" reference="../../.."/>
    <build2 class="build" reference="../../.."/>
    <diffOption>false</diffOption>
    <dataHolders>
    <org.jenkinsci.plugins.buildenvironment.data.EnvVarsData>
    <name>Environment Variables</name>
    <id>envVar</id>
    <data>
    <entry>
    <string>BUILD_CAUSE</string>
    <string>UPSTREAMTRIGGER</string>
    </entry>
    <entry>
    <string>BUILD_CAUSE_UPSTREAMTRIGGER</string>
    <string>true</string>
    </entry>
    <entry>
    <string>BUILD_DISPLAY_NAME</string>
    <string>#2</string>
    </entry>
    <entry>
    <string>BUILD_ID</string>
    <string>2</string>
    </entry>
    <entry>
    <string>BUILD_NUMBER</string>
    <string>2</string>
    </entry>
    <entry>
    <string>BUILD_TAG</string>
    <string>jenkins-test2-2</string>
    </entry>
    <entry>
    <string>CALSSPATH</string>
    <string>.:~/software/java/jdk1.8.0_131/lib/dt.jar:~/software/java/jdk1.8.0_131/lib/tools.jar</string>
    </entry>
    <entry>
    <string>CLASSPATH</string>
    <string>.:/usr/lib/sunJVM/JDK/jdk1.6.0_31/lib</string>
    </entry>
    <entry>
    <string>EXECUTOR_NUMBER</string>
    <string>0</string>
    </entry>
    <entry>
    <string>HOME</string>
    <string>/home/lijing</string>
    </entry>
    <entry>
    <string>HUDSON_HOME</string>
    <string>/home/lijing/.jenkins</string>
    </entry>
    <entry>
    <string>HUDSON_SERVER_COOKIE</string>
    <string>755d2e4d4ac7464c</string>
    </entry>
    <entry>
    <string>JAVA_HOME</string>
    <string>~/software/java/jdk1.8.0_131</string>
    </entry>
    <entry>
    <string>JENKINS_HOME</string>
    <string>/home/lijing/.jenkins</string>
    </entry>
    <entry>
    <string>JENKINS_SERVER_COOKIE</string>
    <string>755d2e4d4ac7464c</string>
    </entry>
    <entry>
    <string>JOB_BASE_NAME</string>
    <string>test2</string>
    </entry>
    <entry>
    <string>JOB_DISPLAY_URL</string>
    <string>http://unconfigured-jenkins-location/job/test2/display/redirect</string>
    </entry>
    <entry>
    <string>JOB_NAME</string>
    <string>test2</string>
    </entry>
    <entry>
    <string>JRE_HOME</string>
    <string>~/software/java/jdk1.8.0_131/jre</string>
    </entry>
    <entry>
    <string>LANG</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LANGUAGE</string>
    <string>zh_CN:zh</string>
    </entry>
    <entry>
    <string>LC_ADDRESS</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_IDENTIFICATION</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_MEASUREMENT</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_MONETARY</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_NAME</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_NUMERIC</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_PAPER</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_TELEPHONE</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_TIME</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LESSCLOSE</string>
    <string>/usr/bin/lesspipe %s %s</string>
    </entry>
    <entry>
    <string>LESSOPEN</string>
    <string>| /usr/bin/lesspipe %s</string>
    </entry>
    <entry>
    <string>LOGNAME</string>
    <string>lijing</string>
    </entry>
    <entry>
    <string>LS_COLORS</string>
    <string>rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:</string>
    </entry>
    <entry>
    <string>MAIL</string>
    <string>/var/mail/lijing</string>
    </entry>
    <entry>
    <string>NLSPATH</string>
    <string>/usr/dt/lib/nls/msg/%L/%N.cat</string>
    </entry>
    <entry>
    <string>NODE_LABELS</string>
    <string>master</string>
    </entry>
    <entry>
    <string>NODE_NAME</string>
    <string>master</string>
    </entry>
    <entry>
    <string>OLDPWD</string>
    <string>/home/lijing/software/apache-tomcat-8.5.16</string>
    </entry>
    <entry>
    <string>PATH</string>
    <string>~/software/java/jdk1.8.0_131/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/sunJVM/JDK/jdk1.6.0_31/bin:/arm/arm-2010.09/bin</string>
    </entry>
    <entry>
    <string>PROMPT_COMMAND</string>
    <string>RETRN_VAL=$?;logger -p local6.debug &quot;$(who am i) [$]: $(history 1 | sed &quot;s/^[ ]*[0-9]\+[ ]*//&quot; ) [$RETRN_VAL]&quot;</string>
    </entry>
    <entry>
    <string>PWD</string>
    <string>/home/lijing/software</string>
    </entry>
    <entry>
    <string>QT_QPA_PLATFORMTHEME</string>
    <string>appmenu-qt5</string>
    </entry>
    <entry>
    <string>REPO_URL</string>
    <string>http://gerrit.allwinnertech.com:8081/git-repo</string>
    </entry>
    <entry>
    <string>ROOT_BUILD_CAUSE</string>
    <string>MANUALTRIGGER</string>
    </entry>
    <entry>
    <string>ROOT_BUILD_CAUSE_MANUALTRIGGER</string>
    <string>true</string>
    </entry>
    <entry>
    <string>RUN_CHANGES_DISPLAY_URL</string>
    <string>http://unconfigured-jenkins-location/job/test2/2/display/redirect?page=changes</string>
    </entry>
    <entry>
    <string>RUN_DISPLAY_URL</string>
    <string>http://unconfigured-jenkins-location/job/test2/2/display/redirect</string>
    </entry>
    <entry>
    <string>SHELL</string>
    <string>/bin/bash</string>
    </entry>
    <entry>
    <string>SHLVL</string>
    <string>1</string>
    </entry>
    <entry>
    <string>SSH_CLIENT</string>
    <string>192.168.206.13 56951 22</string>
    </entry>
    <entry>
    <string>SSH_CONNECTION</string>
    <string>192.168.206.13 56951 192.168.200.89 22</string>
    </entry>
    <entry>
    <string>SSH_TTY</string>
    <string>/dev/pts/16</string>
    </entry>
    <entry>
    <string>TERM</string>
    <string>xterm</string>
    </entry>
    <entry>
    <string>USER</string>
    <string>lijing</string>
    </entry>
    <entry>
    <string>WORKSPACE</string>
    <string>/home/lijing/.jenkins/workspace/test2</string>
    </entry>
    <entry>
    <string>XDG_RUNTIME_DIR</string>
    <string>/run/user/1019</string>
    </entry>
    <entry>
    <string>XDG_SESSION_ID</string>
    <string>4568</string>
    </entry>
    <entry>
    <string>XFILESEARCHPATH</string>
    <string>/usr/dt/app-defaults/%L/Dt</string>
    </entry>
    <entry>
    <string>_</string>
    <string>/home/lijing/software/java/jdk1.8.0_131/bin/java</string>
    </entry>
    </data>
    </org.jenkinsci.plugins.buildenvironment.data.EnvVarsData>
    <org.jenkinsci.plugins.buildenvironment.data.SlaveData>
    <name>Slave Information</name>
    <id>slaveInfo</id>
    <data>
    <entry>
    <string>Busy executors</string>
    <string>1</string>
    </entry>
    <entry>
    <string>CALSSPATH</string>
    <string>.:~/software/java/jdk1.8.0_131/lib/dt.jar:~/software/java/jdk1.8.0_131/lib/tools.jar</string>
    </entry>
    <entry>
    <string>CLASSPATH</string>
    <string>.:/usr/lib/sunJVM/JDK/jdk1.6.0_31/lib</string>
    </entry>
    <entry>
    <string>Computer Heap dump</string>
    <string>hudson.util.RemotingDiagnostics$HeapDump@309c537a</string>
    </entry>
    <entry>
    <string>Computer connect time</string>
    <string>1504138366205</string>
    </entry>
    <entry>
    <string>Computer retention strategy</string>
    <string>hudson.slaves.RetentionStrategy$2@2fb0879</string>
    </entry>
    <entry>
    <string>Demand start in ms</string>
    <string>9223372036854775807</string>
    </entry>
    <entry>
    <string>HOME</string>
    <string>/home/lijing</string>
    </entry>
    <entry>
    <string>Host name</string>
    <string>192.168.122.1</string>
    </entry>
    <entry>
    <string>Is accepting tasks</string>
    <string>true</string>
    </entry>
    <entry>
    <string>JAVA_HOME</string>
    <string>~/software/java/jdk1.8.0_131</string>
    </entry>
    <entry>
    <string>JRE_HOME</string>
    <string>~/software/java/jdk1.8.0_131/jre</string>
    </entry>
    <entry>
    <string>LANG</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LANGUAGE</string>
    <string>zh_CN:zh</string>
    </entry>
    <entry>
    <string>LC_ADDRESS</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_IDENTIFICATION</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_MEASUREMENT</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_MONETARY</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_NAME</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_NUMERIC</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_PAPER</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_TELEPHONE</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LC_TIME</string>
    <string>zh_CN.UTF-8</string>
    </entry>
    <entry>
    <string>LESSCLOSE</string>
    <string>/usr/bin/lesspipe %s %s</string>
    </entry>
    <entry>
    <string>LESSOPEN</string>
    <string>| /usr/bin/lesspipe %s</string>
    </entry>
    <entry>
    <string>LOGNAME</string>
    <string>lijing</string>
    </entry>
    <entry>
    <string>LS_COLORS</string>
    <string>rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:</string>
    </entry>
    <entry>
    <string>MAIL</string>
    <string>/var/mail/lijing</string>
    </entry>
    <entry>
    <string>NLSPATH</string>
    <string>/usr/dt/lib/nls/msg/%L/%N.cat</string>
    </entry>
    <entry>
    <string>Node display name</string>
    <string>Jenkins</string>
    </entry>
    <entry>
    <string>Node label</string>
    <string></string>
    </entry>
    <entry>
    <string>Node mode</string>
    <string>NORMAL</string>
    </entry>
    <entry>
    <string>Node name</string>
    <string></string>
    </entry>
    <entry>
    <string>Node root path</string>
    <string>/home/lijing/.jenkins</string>
    </entry>
    <entry>
    <string>Number of executors</string>
    <string>2</string>
    </entry>
    <entry>
    <string>OLDPWD</string>
    <string>/home/lijing/software/apache-tomcat-8.5.16</string>
    </entry>
    <entry>
    <string>PATH</string>
    <string>~/software/java/jdk1.8.0_131/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/sunJVM/JDK/jdk1.6.0_31/bin:/arm/arm-2010.09/bin</string>
    </entry>
    <entry>
    <string>PROMPT_COMMAND</string>
    <string>RETRN_VAL=$?;logger -p local6.debug &quot;$(who am i) [$$]: $(history 1 | sed &quot;s/^[ ]*[0-9]\+[ ]*//&quot; ) [$RETRN_VAL]&quot;</string>
    </entry>
    <entry>
    <string>PWD</string>
    <string>/home/lijing/software</string>
    </entry>
    <entry>
    <string>QT_QPA_PLATFORMTHEME</string>
    <string>appmenu-qt5</string>
    </entry>
    <entry>
    <string>REPO_URL</string>
    <string>http://gerrit.allwinnertech.com:8081/git-repo</string>
    </entry>
    <entry>
    <string>SHELL</string>
    <string>/bin/bash</string>
    </entry>
    <entry>
    <string>SHLVL</string>
    <string>1</string>
    </entry>
    <entry>
    <string>SSH_CLIENT</string>
    <string>192.168.206.13 56951 22</string>
    </entry>
    <entry>
    <string>SSH_CONNECTION</string>
    <string>192.168.206.13 56951 192.168.200.89 22</string>
    </entry>
    <entry>
    <string>SSH_TTY</string>
    <string>/dev/pts/16</string>
    </entry>
    <entry>
    <string>TERM</string>
    <string>xterm</string>
    </entry>
    <entry>
    <string>USER</string>
    <string>lijing</string>
    </entry>
    <entry>
    <string>XDG_RUNTIME_DIR</string>
    <string>/run/user/1019</string>
    </entry>
    <entry>
    <string>XDG_SESSION_ID</string>
    <string>4568</string>
    </entry>
    <entry>
    <string>XFILESEARCHPATH</string>
    <string>/usr/dt/app-defaults/%L/Dt</string>
    </entry>
    <entry>
    <string>_</string>
    <string>/home/lijing/software/java/jdk1.8.0_131/bin/java</string>
    </entry>
    <entry>
    <string>awt.toolkit</string>
    <string>sun.awt.X11.XToolkit</string>
    </entry>
    <entry>
    <string>executable-war</string>
    <string>/home/lijing/software/jenkins.war</string>
    </entry>
    <entry>
    <string>file.encoding</string>
    <string>UTF-8</string>
    </entry>
    <entry>
    <string>file.encoding.pkg</string>
    <string>sun.io</string>
    </entry>
    <entry>
    <string>file.separator</string>
    <string>/</string>
    </entry>
    <entry>
    <string>idle executors</string>
    <string>1</string>
    </entry>
    <entry>
    <string>is Hold off launch until save</string>
    <string>false</string>
    </entry>
    <entry>
    <string>java.awt.graphicsenv</string>
    <string>sun.awt.X11GraphicsEnvironment</string>
    </entry>
    <entry>
    <string>java.awt.headless</string>
    <string>true</string>
    </entry>
    <entry>
    <string>java.awt.printerjob</string>
    <string>sun.print.PSPrinterJob</string>
    </entry>
    <entry>
    <string>java.class.path</string>
    <string>jenkins.war</string>
    </entry>
    <entry>
    <string>java.class.version</string>
    <string>52.0</string>
    </entry>
    <entry>
    <string>java.endorsed.dirs</string>
    <string>/home/lijing/software/java/jdk1.8.0_131/jre/lib/endorsed</string>
    </entry>
    <entry>
    <string>java.ext.dirs</string>
    <string>/home/lijing/software/java/jdk1.8.0_131/jre/lib/ext:/usr/java/packages/lib/ext</string>
    </entry>
    <entry>
    <string>java.home</string>
    <string>/home/lijing/software/java/jdk1.8.0_131/jre</string>
    </entry>
    <entry>
    <string>java.io.tmpdir</string>
    <string>/tmp</string>
    </entry>
    <entry>
    <string>java.library.path</string>
    <string>/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib</string>
    </entry>
    <entry>
    <string>java.runtime.name</string>
    <string>Java(TM) SE Runtime Environment</string>
    </entry>
    <entry>
    <string>java.runtime.version</string>
    <string>1.8.0_131-b11</string>
    </entry>
    <entry>
    <string>java.specification.name</string>
    <string>Java Platform API Specification</string>
    </entry>
    <entry>
    <string>java.specification.vendor</string>
    <string>Oracle Corporation</string>
    </entry>
    <entry>
    <string>java.specification.version</string>
    <string>1.8</string>
    </entry>
    <entry>
    <string>java.vendor</string>
    <string>Oracle Corporation</string>
    </entry>
    <entry>
    <string>java.vendor.url</string>
    <string>http://java.oracle.com/</string>
    </entry>
    <entry>
    <string>java.vendor.url.bug</string>
    <string>http://bugreport.sun.com/bugreport/</string>
    </entry>
    <entry>
    <string>java.version</string>
    <string>1.8.0_131</string>
    </entry>
    <entry>
    <string>java.vm.info</string>
    <string>mixed mode</string>
    </entry>
    <entry>
    <string>java.vm.name</string>
    <string>Java HotSpot(TM) 64-Bit Server VM</string>
    </entry>
    <entry>
    <string>java.vm.specification.name</string>
    <string>Java Virtual Machine Specification</string>
    </entry>
    <entry>
    <string>java.vm.specification.vendor</string>
    <string>Oracle Corporation</string>
    </entry>
    <entry>
    <string>java.vm.specification.version</string>
    <string>1.8</string>
    </entry>
    <entry>
    <string>java.vm.vendor</string>
    <string>Oracle Corporation</string>
    </entry>
    <entry>
    <string>java.vm.version</string>
    <string>25.131-b11</string>
    </entry>
    <entry>
    <string>jna.loaded</string>
    <string>true</string>
    </entry>
    <entry>
    <string>jna.platform.library.path</string>
    <string>/usr/lib/x86_64-linux-gnu:/lib/x86_64-linux-gnu:/lib64:/usr/lib:/lib:/lib/i386-linux-gnu:/usr/lib32:/usr/lib/i386-linux-gnu:/libx32:/lib32:/usr/libx32:/usr/lib/x86_64-linux-gnu/libfakeroot:/usr/lib/x86_64-linux-gnu/mesa-egl:/usr/lib/x86_64-linux-gnu/mesa:/usr/lib/i386-linux-gnu/mesa</string>
    </entry>
    <entry>
    <string>jnidispatch.path</string>
    <string>/tmp/jna--1102787019/jna6439914840531682012.tmp</string>
    </entry>
    <entry>
    <string>line.separator</string>
    <string>
    </string>
    </entry>
    <entry>
    <string>mail.smtp.sendpartial</string>
    <string>true</string>
    </entry>
    <entry>
    <string>mail.smtps.sendpartial</string>
    <string>true</string>
    </entry>
    <entry>
    <string>os.arch</string>
    <string>amd64</string>
    </entry>
    <entry>
    <string>os.name</string>
    <string>Linux</string>
    </entry>
    <entry>
    <string>os.version</string>
    <string>3.19.0-69-generic</string>
    </entry>
    <entry>
    <string>path.separator</string>
    <string>:</string>
    </entry>
    <entry>
    <string>sun.arch.data.model</string>
    <string>64</string>
    </entry>
    <entry>
    <string>sun.boot.class.path</string>
    <string>/home/lijing/software/java/jdk1.8.0_131/jre/lib/resources.jar:/home/lijing/software/java/jdk1.8.0_131/jre/lib/rt.jar:/home/lijing/software/java/jdk1.8.0_131/jre/lib/sunrsasign.jar:/home/lijing/software/java/jdk1.8.0_131/jre/lib/jsse.jar:/home/lijing/software/java/jdk1.8.0_131/jre/lib/jce.jar:/home/lijing/software/java/jdk1.8.0_131/jre/lib/charsets.jar:/home/lijing/software/java/jdk1.8.0_131/jre/lib/jfr.jar:/home/lijing/software/java/jdk1.8.0_131/jre/classes</string>
    </entry>
    <entry>
    <string>sun.boot.library.path</string>
    <string>/home/lijing/software/java/jdk1.8.0_131/jre/lib/amd64</string>
    </entry>
    <entry>
    <string>sun.cpu.endian</string>
    <string>little</string>
    </entry>
    <entry>
    <string>sun.cpu.isalist</string>
    <string></string>
    </entry>
    <entry>
    <string>sun.font.fontmanager</string>
    <string>sun.awt.X11FontManager</string>
    </entry>
    <entry>
    <string>sun.io.unicode.encoding</string>
    <string>UnicodeLittle</string>
    </entry>
    <entry>
    <string>sun.java.command</string>
    <string>jenkins.war</string>
    </entry>
    <entry>
    <string>sun.java.launcher</string>
    <string>SUN_STANDARD</string>
    </entry>
    <entry>
    <string>sun.jnu.encoding</string>
    <string>UTF-8</string>
    </entry>
    <entry>
    <string>sun.management.compiler</string>
    <string>HotSpot 64-Bit Tiered Compilers</string>
    </entry>
    <entry>
    <string>sun.os.patch.level</string>
    <string>unknown</string>
    </entry>
    <entry>
    <string>svnkit.http.methods</string>
    <string>Digest,Basic,NTLM,Negotiate</string>
    </entry>
    <entry>
    <string>svnkit.ssh2.persistent</string>
    <string>false</string>
    </entry>
    <entry>
    <string>user.country</string>
    <string>CN</string>
    </entry>
    <entry>
    <string>user.dir</string>
    <string>/home/lijing/software</string>
    </entry>
    <entry>
    <string>user.home</string>
    <string>/home/lijing</string>
    </entry>
    <entry>
    <string>user.language</string>
    <string>zh</string>
    </entry>
    <entry>
    <string>user.name</string>
    <string>lijing</string>
    </entry>
    <entry>
    <string>user.timezone</string>
    <string>Asia/Shanghai</string>
    </entry>
    </data>
    </org.jenkinsci.plugins.buildenvironment.data.SlaveData>
    <org.jenkinsci.plugins.buildenvironment.data.ProjectData>
    <name>Project Information</name>
    <id>projectInfo</id>
    <data>
    <entry>
    <string>Abort permission</string>
    <string>true</string>
    </entry>
    <entry>
    <string>Block when downstream building</string>
    <string>false</string>
    </entry>
    <entry>
    <string>Block when upstream building</string>
    <string>false</string>
    </entry>
    <entry>
    <string>Is buildable</string>
    <string>true</string>
    </entry>
    <entry>
    <string>Is concurrent build</string>
    <string>false</string>
    </entry>
    <entry>
    <string>Is disabled</string>
    <string>false</string>
    </entry>
    <entry>
    <string>Is fingerprint configured</string>
    <string>false</string>
    </entry>
    <entry>
    <string>Is name editable</string>
    <string>true</string>
    </entry>
    <entry>
    <string>Is parameterized</string>
    <string>false</string>
    </entry>
    <entry>
    <string>Project name</string>
    <string>test2</string>
    </entry>
    <entry>
    <string>Project url</string>
    <string>job/test2/</string>
    </entry>
    <entry>
    <string>Quiet period</string>
    <string>5</string>
    </entry>
    <entry>
    <string>SCM</string>
    <string>hudson.scm.NullSCM@c21addb</string>
    </entry>
    <entry>
    <string>SCM type</string>
    <string>hudson.scm.NullSCM</string>
    </entry>
    </data>
    </org.jenkinsci.plugins.buildenvironment.data.ProjectData>
    </dataHolders>
    </org.jenkinsci.plugins.buildenvironment.actions.BuildEnvironmentBuildAction>
    </actions>
    <queueId>2</queueId>
    <timestamp>1504138435886</timestamp>
    <startTime>1504138435887</startTime>
    <result>SUCCESS</result>
    <duration>68</duration>
    <charset>UTF-8</charset>
    <keepLog>false</keepLog>
    <builtOn></builtOn>
    <workspace>/home/lijing/.jenkins/workspace/test2</workspace>
    <hudsonVersion>2.60.1</hudsonVersion>
    <scm class="hudson.scm.NullChangeLogParser"/>
    <culprits class="com.google.common.collect.EmptyImmutableSortedSet"/>
    </build>

  55. Hi,

    Please help me out form this.

    I have configured 'Trigger parameterized build' in my post build section of 'job A' to trigger 'job B', Every thing working fine, but my issue is, after triggering 'job B' by 'job A'. 'job A' is keeps on loading until 'job B' finished the execution. How can i make the 'job A' finished, why because some of our downstream  will run for 24,48 and 72 hours.which means i have to wait for more than 24hrs to run next job or else i need to configure  "enable concurrent build if necessary" option form job configuration.

    Can some one please tell me if there is such option to finish the job once it trigger downstrem job.

  56. Build Blocker Plugin - you can block execution of job B untill job A completes. 

  57. When using the "For every property file, invoke one build" ParameterFactory, are the builds started in parallel? Could you please update the documentation? Thanks!

  58. I'm not seeing how this can be used with pipeline. Checked the pipeline syntax generator and nothing for this plugin after it's installed. Anyone??

    1. Hope you found a solution to this; I'll post a partial one that worked for my uses.

      It is derived heavily from a Stackoverflow post and is implemented with the regular build step:


      def topLevelParams = currentBuild.rawBuild.getAction(ParametersAction).getParameters()
      build job: 'anotherJob', parameters: topLevelParams, propagate: true



      The regular build step works with individuals argument (ex "build job: 'anotherJob', parameters: [[$class: 'BooleanParameterValue', name: 'BAR', value: this.foo]]"). This is less than this plugin can do but those two use cases, forward all parameters or send some parameters, accomplished my use cases. The former requires a lot of script approvals whereas the latter is less constrained.

      1. Thanks for the response. 

        Yep!  I found the same result, that the regular build step can pass parameters (smile) 

  59. Jenkins v2.89.4  and Parameterized Trigger Plugin v2.35.2

    I have a job that executes a shell which works out which downstream job (or jobs) needs to be triggered using the parameterized trigger plugin.

    This information is passed back to the job in an environment variable called BUILD_JOBS.

    These jobs are in folders e.g. Folder1/job/Folder2/job/job-to-run

    When I use ${BUILD_JOBS} as the value for 'Projects to build', the job fails when it run stating that the project can't be resolved.

    I know that jenkins can resolve the project because using the URL http:/jenkins-server/job/Folder1/job/Folder2/job/job-to -run takes me to the job.

    Am I doing something wrong or are folders not supported?

     

    Thanks.

  60. SOLVED!

    The value passed in the variable should be like Folder1/Folder2/job-to-run

Write a comment…