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 <mish...@gmail.com> 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 jenkinsci-users+unsubscr...@googlegroups.com. > 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 jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
