Great idea. Thanks, that sounds like it would work!
On Tue, Aug 6, 2013 at 2:28 PM, Daniel Beck <[email protected]> wrote: > You could use the parameterized trigger plugin and use the build step as > the first action in the upstream build. > > That way, B will be queued before A polls SCM again. If necessary, add a > Quiet Period to A in its advanced project options for the time it takes A > to check out from SCM (or rather, to offset the delay from build start to > first build step). > > On 06.08.2013, at 22:55, Mishael Kim <[email protected]> wrote: > > > Hi All, > > > > Job A is a build job that is triggered by SCM changes, and Job B is a > downstream test job configured to use the same node and same workspace. > > > > If Job A #1 is currently running, and Job A receives another trigger > from SCM (Job A #2), how do I ensure that Job B #1 (which hasn't been > triggered yet) takes precedence over Job A #2 for that one executor spot > available on the machine? > > > > Thanks, > > Mishael > > > > -- > > You received this message because you are subscribed to the Google > Groups "Jenkins Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
