Yeah. I don't like this behavior either. It's 'wait for people to get their
non-atomic SCM commits right', rather than 'prevent back-to-back executions'
(the clock starts ticking when it enters the queue, not when the previous build
is finished) -- I'd need the latter more than the former...
On
Daniel,
Slight problem with adding a quiet period to A... the first manually
triggered job will have to wait for that quiet period as well, even if
there's nothing running in the pipeline. Not a deal breaker, but I could
see this being pretty annoying.
On Wed, Aug 7, 2013 at 10:39 AM, Mishael K
Great idea. Thanks, that sounds like it would work!
On Tue, Aug 6, 2013 at 2:28 PM, Daniel Beck 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
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, t
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 triggere
