Yes, I agree. But in this case, its not an automated polling system which
would be queuing up the builds, but actual SCM triggers queuing them up. If
the build pipeline is unable to cope up with the speed of development, we
may want to look at ways to speed-up the pipeline. Maybe setting up a
'
Yes, I agree. But in this case, its not an automated polling system which
would be queuing up the builds, but actual SCM triggers queuing them up. If
the build pipeline is unable to cope up with the speed of development, we
may want to look at ways to speed-up the pipeline. Maybe setting up a
'free
Unfortunately that will end in the same result. If a new SCM build is
queued before the previous pipeline is done (regardless if that is from a
poll or a push), then I'm in this situation.
On Monday, August 1, 2016 at 5:20:58 PM UTC-5, Mrinal Mukherjee wrote:
>
> Hi Chris,
>
> This may not be t
Hi Chris,
This may not be the solution you are looking for. Do you think using a
webhook (to trigger a job when a change is pushed to source control) would
be a better bet than a poll SCM option?
Mrinal
On Tue, Aug 2, 2016 at 9:26 AM, Chris Shannon wrote:
> I have a set of builds chained toget
I have a set of builds chained together using the Parameterized Trigger
Plugin. The starting build polls SCM and then kicks off build/test/deploy
jobs which all run on the same node and reuse the same codebase established
in the SCM job.
This seems like a pretty standard/basic thing, but I'm r
