Looks like you really want the parameterized-trigger with more conditions, this is currently a pull request which make the parameterized-trigger have all of the same conditions as the conditional build step plugin.
If you want to try this it is request https://github.com/jenkinsci/parameterized-trigger-plugin/pull/17 Warning Using this version means that you can't go back to the 2.xx versions so best to try it on a test server first. Test file at https://github.com/cjo9900/parameterized-trigger-plugin/tree/target-file/target Chris On Wednesday, July 11, 2012 10:33:06 AM UTC+1, Jan Seidel wrote: > > Never mind, > > seems that I have been mixing my memories up. Seems that it not is > possible to keep dispatcher running and wait for the child job in multiple > instances. Even if I actually still am convinced that it did work. > Removing the Block option in the conditional build trigger solves it so > far. > > Take care > Jan > > Am Mittwoch, 11. Juli 2012 11:11:08 UTC+2 schrieb Jan Seidel: >> >> Hi folks, >> >> I am facing some funny (well...not) situation. >> My current project involves also some serious parallelization. >> >> There is one main job doing some unspectacular operations like string >> split and compare in order to decide via conditional build steps which job >> has to be launched. So I call it the dispatcher. >> The downstream jobs have all their own dedicate executor assigned while >> the dispatcher may roam to any executor available except for the dedicated >> ones. >> >> So far so good. BUT the downstream jobs don't do run in parellel. There >> are several dispatchers running but all except one are on hold until the >> active has finished and the next one starts. >> The build log says nothing. >> I can see that it finishes the last build step before the conditional >> build and then simply does nothing without any notice. >> >> I have while troubleshooting set *"allow concurrent builds*" for the >> dispatcher and all the downstream jobs - no luck. >> I removed the setting *"Block until finished"* in the conditional >> trigger step in the dispatcher - still no joy. >> >> I know for sure that it did work with parallel builds. It was a major >> issue in the past and the reworked buildsystem did it as proof of concept >> the right way. >> Do I miss some setting or does someone know this behaviour? >> >> Cheers >> Jan >> > On Wednesday, July 11, 2012 10:33:06 AM UTC+1, Jan Seidel wrote: > > Never mind, > > seems that I have been mixing my memories up. Seems that it not is > possible to keep dispatcher running and wait for the child job in multiple > instances. Even if I actually still am convinced that it did work. > Removing the Block option in the conditional build trigger solves it so > far. > > Take care > Jan > > Am Mittwoch, 11. Juli 2012 11:11:08 UTC+2 schrieb Jan Seidel: >> >> Hi folks, >> >> I am facing some funny (well...not) situation. >> My current project involves also some serious parallelization. >> >> There is one main job doing some unspectacular operations like string >> split and compare in order to decide via conditional build steps which job >> has to be launched. So I call it the dispatcher. >> The downstream jobs have all their own dedicate executor assigned while >> the dispatcher may roam to any executor available except for the dedicated >> ones. >> >> So far so good. BUT the downstream jobs don't do run in parellel. There >> are several dispatchers running but all except one are on hold until the >> active has finished and the next one starts. >> The build log says nothing. >> I can see that it finishes the last build step before the conditional >> build and then simply does nothing without any notice. >> >> I have while troubleshooting set *"allow concurrent builds*" for the >> dispatcher and all the downstream jobs - no luck. >> I removed the setting *"Block until finished"* in the conditional >> trigger step in the dispatcher - still no joy. >> >> I know for sure that it did work with parallel builds. It was a major >> issue in the past and the reworked buildsystem did it as proof of concept >> the right way. >> Do I miss some setting or does someone know this behaviour? >> >> Cheers >> Jan >> >
