Plugin Information
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.
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 _). |
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.
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. A recent Git runtime is required (1.7.9 minimum, 1.8.x recommended). Plugin is only tested on official git client. Use exotic installations at your own risks.
|
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:
- 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:
- In RedHat Linux systems, you can modify /etc/sysconfig/jenkins as following:
- In Debian Linux systems, you can modify /etc/defaults/jenkins as following:
- In Windows system, you can modify jenkins.xml placed in the installed folder.
Changelog
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. (issue #25772)
- Add FAILURE_OR_BETTER Trigger Threshold. (issue #26029)
- Rely on archived artifacts to trigger (parameterized) build fallback to workspace for backward compatibility. (issue #25192)
- Added export of triggered builds and jobs to XML/JSON API. (issue #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. (issue #22705)
- Support absolute paths in "Parameters from properties file". (issue #23084)
- Allow using parameter files even if no workspace exists. (issue #22229)
- Output more informative logs when failing converting parameter values in compatibility mode. (issue #22281)
- FIXED: Checking project names in configuration page works wrong with Cloudbees Template plugin. (issue #22856)
2.24 (Mar 16, 2014)
- This is a release to provide backward compatibility with Parameterized Trigger Plugin <= 2.22 (issue #22125).
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() (issue #20932)
- Supports property files with non-ascii characters. This feature only works properly in Java 1.6, but Java 1.5 is still supported. (issue #19990, issue #20651)
- Matrix project support for "Parameters from properties file". (issue #21013)
- Added license notice (MIT) (issue #21270)
2.22 (Dec 13, 2013)
- Fixed projects.size to projects.size() in groovy script. This caused exception with IBM Java 6. (issue #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 (issue #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 (issue #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 (issue #11669)
- Allow speciying Git SHA1 commit id for next build(s) as Predefined parameter (issue #13852)
- Counter/File Parameter Factories now can prevent triggering, skip adding parameteers or fail the build if errors occur. (issue #13872)
- A parameterized buildstep in a matrix project causes IllegalArgumentException (issue #14278)
- Unusable environment variable TRIGGERED_BUILD_NUMBER_jobname (issue #14545)
- It's not possible to specify multiple property files in parametrised trigger (issue #15834)
- Boolean parameter becomes string (issue #15920)
- Define impllicit parameter: "build them on the same node" (issue #16334)
| Note
Environment parameter names have changed from previous version, due to fix for (issue #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 (issue #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!). (issue #8916)
- Fix triggering projects based on variables (issue #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. (issue #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. (issue #11082, issue #9263, issue #5184)
- Info on builds kicked off as blocking build steps exposed. (issue #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. (issue #11116, issue #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 issue #10028: Textbox for downstream projects should be validated as with the "Build other projects" text box.
- Implemented issue #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. (issue #8985)
- Implemented issue #9217: Added a new option to not run further build steps if triggered builds fail or are unstable
- Implemented issue #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. (issue #6141)
- Add support for multiconfiguration(matrix) projects. (issue #5687)
- Fix variable expansion in "predefined parameters" so backslashes in variable values are not lost. Add help text about backslash handling. (issue #6004)
- File parameters are currently not reusable, so omit these when "current build parameters" is selected. (issue #6777)
- Update trigger settings when other jobs are renamed or deleted. (issue #6483)
- Add an "always trigger" option. (issue #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. (issue #5184)
- Merge together parameter lists from multiple sources to avoid multiple Parameters links on build pages (issue #5143) and failure to pass some parameters further along the downstream chain (issue #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. (issue #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)
Gliffy Diagram
Edit in Word
Parameterized Trigger Plugin
Comments (67)
Jun 01, 2009
amby - says:
Is it possible to use current build parameters to form parameters of downstream ...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}Jun 11, 2009
amby - says:
Implemented.Implemented.
Jun 30, 2009
Joe Stano says:
How about using the parameters passed by this plugin in an SVN URL? I know...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.
Jul 01, 2009
amby - says:
I've tested this out today with latest versions of Hudson and Parameterized Trig...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?
Jul 13, 2009
glundh - says:
Great plugin! There is a few things I cannot get working though. Hopefully ...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
Jul 18, 2009
amby - says:
It seems that "Downstream Projects" and "Upstream Projects" sections are built-i...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
Aug 10, 2009
amby - says:
Was there any specific reason for removing batch condition? It was really useful...Was there any specific reason for removing batch condition? It was really useful. Can you suggest another way for conditional project building in Hudson?
Aug 13, 2009
sven - says:
I absolutely need the batch conditions. The batch conditions are used to make it...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.
Aug 28, 2009
sven - says:
Any chance you might reconsider the removal of the batch conditions? Please?Any chance you might reconsider the removal of the batch conditions? Please?
Sep 12, 2009
oliviera - says:
I also really need this feature, there's currently no other way to implement con...I also really need this feature, there's currently no other way to implement conditional chaining in Hudson.
Oct 21, 2009
holywen - says:
Yes, this batch conditions is really useful, please consider add it back. BTW, ...Yes, this batch conditions is really useful, please consider add it back.
BTW, any document about how to contribute to the parameter section?
Jul 06, 2011
Salman Awan says:
Definitely, Conditionally initiating builds based on parameters is perfect place...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.
Sep 16, 2009
Andrey says:
Is it possible to run parameterized build remotely from the script ? I was try...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 ?
Sep 25, 2009
György Földvári says:
It seems, that actual triggering is blocked, if there are no parameters given, e...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?
Dec 10, 2009
Max Khon says:
For multiconfiguration project the build is triggered for each configuration, un...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?
Dec 16, 2009
Shimi says:
How can I use the "Subversion revision" in the triggered project?How can I use the "Subversion revision" in the triggered project?
Dec 21, 2009
venkatasatyanarayana says:
I have configured 2 jobs A and B, A should call B on success with parameters. U...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.
Feb 04, 2010
markjwolff - says:
I use the SVN revision option. It works very nicely. Is there a way...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.
Mar 25, 2010
Michael Legner says:
How did you get it working? I kinda stuck with it, Hudson can't check out from m...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 existi've also tried @$SVN_REVISION and @%SVN_REVISION%, but the same error occurred. If I put a number at the place instead, it works.
Apr 06, 2010
markjwolff - says:
You are working too hard. It appears that as long as the master job is set...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.
Apr 07, 2010
Michael Legner says:
unfortunatly, it doesn't, at least not at my installation. I've already put the ...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
Feb 22, 2010
Jason Stiefel says:
Great plugin! But we are in serious need of support for triggering a build a...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!
Apr 06, 2010
markjwolff - says:
I've had trouble using variables with periods or underscores in them on Linux jo...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.
Mar 25, 2010
massimo tedesco says:
I would like to use this plugin to build project A, project C and project B in t...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
May 21, 2010
Mikael F says:
Can anyone answer this? http://hudson.361315.n4.nabble.com/Trigger-parameterize...Can anyone answer this?
http://hudson.361315.n4.nabble.com/Trigger-parameterized-build-on-other-projects-Plugin-td2226975.html#a2226975
Aug 03, 2010
Jean-Luc Pinardon says:
It appears that it doesn't work altogether with the Join Plugin. Once the Parame...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....
Aug 03, 2010
Jean-Luc Pinardon says:
I have a top job which launch a downstream job using the parameterized trigger p...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.
Nov 30, 2010
Peter Schuetze says:
Write the new parameters in a file. And use file parameters when triggering the ...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.
Aug 19, 2010
Owen Urkov says:
Are there detailed instructions for using this plugin anywhere? I have a p...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! :)
Sep 08, 2010
Julien Ducrey says:
Hi, i have a simple question : Is it possible to launch parametrized trigger w...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.
Oct 05, 2010
prash says:
I am trying to use parameter trigger plugin, however facing some issues. In the ...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.
Nov 03, 2010
Louis Henry Nayegon says:
I have tried to trigger a job to run 3 time with 3 lots of parameters at the end...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 ?
Nov 17, 2010
Craig Thayer says:
Is there a way to disable a downstream parameterized job programmatically? We h...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.
Dec 14, 2010
Ken Van Hoeylandt says:
Hi Craig, We're currently experimenting with this, and the approach we've tried...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?
Dec 14, 2010
Peter Schuetze says:
Hi Ken, same solution for you as well. As the last build step, use the remote A...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
Dec 14, 2010
Peter Schuetze says:
Hi Craig, This mechanism is not implemented at all in Hudson. But there is help...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
Jan 19, 2011
Amir Katz says:
It seems that the plug-in is broken in the latest Hudson version, 1.394. The dow...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
Jan 24, 2011
Alan Harder says:
Someone else mentioned this in IRC, but when I tried it I couldn't find any prob...Someone else mentioned this in IRC, but when I tried it I couldn't find any problems (tried "on success" and "on failed" triggers).
Jan 25, 2011
Amir Katz says:
I upgraded my Hudson installation to the latest (1.395) and the plug-in seem to ...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
Feb 15, 2011
Jean-Luc Pinardon says:
Hello, When configuring some downstreams jobs with parameters to pass for all ...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
Mar 11, 2011
Duncan Sommerville says:
I want to trigger two instances of the same downstream job following successful ...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?
Apr 12, 2011
Maxim Kolchin says:
I have same question. I asked it here http://stackoverflow.com/questions/5624829...I have same question. I asked it here http://stackoverflow.com/questions/5624829/how-start-identical-jobs-with-different-parameters-in-parallel-execution
Jun 01, 2011
Daniel Tkatch says:
At the moment one can trigger several projects by providing "a comma separa...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.?
Jul 11, 2011
David Mueller says:
With the new 2.9 version how do I trigger the project using a variable?With the new 2.9 version how do I trigger the project using a variable?
Jul 11, 2011
Fred G says:
Just to clarify, the description of JENKINS-9391 says: "The goal here is for the...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
Dec 11, 2012
Michael Conlon says:
I've tried this, in the most simple scenario possible, but I can't get it to wor...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?
Sep 12, 2011
Adam Monsen says:
When I "Pass through Git Commit that was built", is the GIT_COMMIT environment v...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
Oct 06, 2011
Massimo Rossello says:
User permissions are not kept in a triggered project, which can run as if trigge...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
Jan 08, 2012
edbras - says:
How is it possible to let the plugin pass parameters to all automatically detect...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
Jan 23, 2012
Oleksandr Popov says:
I have issue (https://issues.jenkins-ci.org/browse/JENKINS-12113): Maven - ja...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!
Jan 23, 2012
Peter Schuetze says:
I am not sure why u ask this question here. The ticket confirmed, that it is an ...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.
Jan 24, 2012
Oleksandr Popov says:
Hi Peter, I'm asking this question because I suspect that Parameterized Trigger...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!
Feb 15, 2012
Nathan Perrier says:
For the param 'types', would it be possible to add a 'datetime' so that when i r...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.
Jul 25, 2012
Sean Houghton says:
Why aren't the parameter factories available in the post-build instance of this ...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
Aug 16, 2012
Pedro Correia says:
Hi there, I was wondering if anyone can help me with a problem. I'm running Je...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 2012Any thoughts on this? Is it a bug?
Aug 17, 2012
Pedro Correia says:
Nevermind, I should have googled better. For those interested, this is bug ...Nevermind, I should have googled better. For those interested, this is bug 14495 and it has been fixed in version 1.477.
Aug 17, 2012
lionel alberti says:
I'm using a matrix configuration job to trigger one other build job for each set...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.
Mar 19, 2013
Shanghai Fu says:
hi, this plugin is very usefull! but I want to trigger different job accord...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?
Mar 19, 2013
Peter Schuetze says:
Use the Conditional Build step plugin (https://wiki.jenkins-ci.org/display/JENKI...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.
Mar 20, 2013
Shanghai Fu says:
hi, thanks for your quick reply!! I just try with your suggestioin, maybe it'...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!
Jun 18, 2013
rose red says:
Howdi folks, i am trying to schedule build, but need to pass parameters to comp...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
Jul 29, 2013
mgy tdxmgy says:
I can't upload about 4G large file to jenkins by file parameterized,when i...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?
Oct 30, 2013
Thorsten Meinl says:
We are experiencing some strange behaviour since the last update: downstream job...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.
Aug 22, 2014
Chris Del Checcolo says:
Has anyone experienced the problem where the upstream project loses track of the...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.
Nov 21, 2014
Mykola Grybyk says:
How can I start job like QA_SSM_AUTOCONFIG_StartTests/slave=master,ssmEnv=stl-a...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.
Mar 20
Yang Li says:
Hi, I encountered issue when attempting to access parameterized triggered...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!
May 04
Travis Flint says:
Is there a way to have it evaluate an expression? I want to do an assignme...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?
Add Comment