Parameterized Trigger Plugin

Plugin Information

Plugin ID parameterized-trigger
Latest Release 2.17-h-1
Latest Release Date Nov 13, 2012
Sources Github
Support Eclipse Hudson Forum
Issue Tracking Eclipse Bugzilla

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.

The parameter section is itself pluggable, and other plugins can contribute other sources of parameters.

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

Changelog

2.5 (upcoming)

  • Added a mechanism to call other builds synchronously and map their results.
  • Promotion plugin does not run parameterized builds. (issue #5679)

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 Hudson 1.341 but works with Hudson 1.319 or higher.
  • Implement Hudson API so connected jobs show in Upstream/Downstream Projects list on job pages with Hudson 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 Hudson 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 Hudson 1.285. Hudson 1.286 is a minimum requirement for this version.

1.0, 1.1 (Feb 9, 2009)

  • Initial release

Labels:

plugin-trigger plugin-trigger Delete
tier2-plugin tier2-plugin Delete
tier3-hudson-plugin tier3-hudson-plugin Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
  1. Jun 01, 2009

    Maxim Ilinykh 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}
    
    1. Jun 11, 2009

      Maxim Ilinykh says:

      Implemented.

      Implemented.

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

    1. Jul 01, 2009

      Maxim Ilinykh 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?

  3. Jul 13, 2009

    Gustaf Lundh 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

    1. Jul 18, 2009

      Maxim Ilinykh 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

  4. Aug 10, 2009

    Maxim Ilinykh 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?

    1. Aug 13, 2009

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

      1. Aug 28, 2009

        Sven Kirmess 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?

        1. Sep 12, 2009

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

          1. Oct 21, 2009

            Shaohua Wen 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?

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

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

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

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

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

  10. Feb 04, 2010

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

    1. 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 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. Apr 06, 2010

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

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

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

  12. Apr 06, 2010

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

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

  14. May 21, 2010

    Micke says:

    Can anyone answer this? http://hudson.361315.n4.nabble.com/Trigger-parameterize...
  15. 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....

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

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

  17. 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!  :)

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

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

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

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

    1. Dec 14, 2010

      Ken Beal 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?

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

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

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

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

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

  24. Feb 16, 2011

    vladimir knajtner says:

    Need an ability to trigger a job based on a condition that is more complex than ...

    Need an ability to trigger a job based on a condition that is more complex than current job status.  This would allow me to, say, trigger regression testing once a day after successful snapshot build.  Snapshot builds would run several times a day without triggering regression testing.

  25. Jun 12, 2011

    Ratn Deo Dwivedi says:

    Great Plugin .I am missing some programmable condition inclusion -might be I so...

    Great Plugin .I am missing some programmable condition inclusion -might be I some condition in groovy/ant and based on exit status decide to trigger.

  26. Nov 29, 2011

    Patrick McKeown says:

    Thanks for the amazing plugin, it has been very useful. Recently I've wanted to...

    Thanks for the amazing plugin, it has been very useful. Recently I've wanted to trigger independent downstream builds in parallel while still blocking for their return (to speed up builds while still failing if something goes wrong downstream), but currently triggering multiple builds with blocking runs them serially (might even have been intended). Is this is a feature you might consider implementing or is there a way to achieve this I'm not aware of?