Parameterized Trigger Pipeline

[Chris Shannon]

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 running into a problem keeping the SCM poll job from running again until all of the builds in my "pipeline" are complete.  If the poll job wakes up, it will insert itself in the queue before some of my test/deploy jobs, change the underlying SCM codebase, and royally mess things up.  I've looked at plugins like Build Blocker and Lockable Resources, but none of these seem to handle these triggered jobs (they can handle jobs that are already queued, but not jobs yet to be triggered).

I think that I'm doing something basic here - what am I missing?  Do I really need to write to lock files on my hard drive to handle this?

Note that I'm not using Jenkins pipeline/workflow because it does not yet support ClearCase, but I realize that life would probably be easier if I was...

Thanks!

[Mrinal Mukherjee]

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

--
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-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/4d84c91d-3327-434f-a195-61d2a46ac221%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Shannon]

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.

[Mrinal Mukherjee]

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 'freeze/delay' between 2 consecutive builds could help ensure that the jobs dont queue up because of multiple commits occurring over a short time interval.

Anyway, I'm sorry if I am going off at a tangent. As I said, this may not be the solution you are looking for.