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.

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

TRIGGERED_BUILD_RUN_COUNT_project name>="Number of builds triggered for the project"

From 2.17 onwardsAll 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:

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.

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() (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)

Define impllicit parameter: "build them on the same node" (issue #16334)

NoteEnvironment 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 _

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

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?

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?

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.

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.

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.

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?

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)

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.

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

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.

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.

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!

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.

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.

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.

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?

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.

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 ?

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

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

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.

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?

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.

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.

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.

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?

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 2012

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

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.

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.

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.