I did some tests and it appears to merge, or rather, schedulebuild2 just returns the instance of the already queued job from a previous scheduledbuild2 as you suggested, that's incredibly annoying, so I guess one has to take a snapshot of the build queue then schedulebuild2, if it's already in the queue, assume a refused. And of course hope the queue doesn't change between those operations. Wow. :)
On Friday, May 20, 2016 at 10:33:08 AM UTC+1, Niksan wrote: > > I'm not sure under what circumstances an item merge occurs, but that would > be problematic, as it would be waiting on someone else's job and tying a > node up needlessly. > > Scraping though the code on GitHub last night I saw there is a check to > see if scheduling should happen, one of the simple checks being a like for > like and returns with ScheduleResult.Refused > <http://javadoc.jenkins-ci.org/hudson/model/queue/ScheduleResult.Refused.html> > which is a shame that's not propagated up, however, it does seem that you > can assume when the future is done and getJob yields null, it never > started, I guess with a mixture of cancel checks and what not could > determine the actual cause. > > I'd have to run some tests to see what means what. > > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/16e8260f-839e-41e7-ad74-472b0269c092%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
