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. On Thursday, May 19, 2016 at 8:09:22 PM UTC+1, Daniel Beck wrote: > > > > On 19.05.2016, at 15:37, 'Niksan' via Jenkins Users < > [email protected] <javascript:>> wrote: > > > > So, you can fire jobs off in Groovy using ScheduleBuild2 which returns a > future. By its nature, Jenkins will purge any duplicate build requests at > some point. > > ParameterizedJobMixin#scheduleBuild2(int, List) returns a Queue.Item, or > null of scheduling failed. If the item was merged, you get a previously > existing Queue.Item. > > Using its #getId() you can continue to query the Queue#getItem(long) for > state transitions, e.g. whether it becomes a Queue.LeftItem, and if so, > check its #isCancelled(). > > -- 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/bbef7530-aa41-49d4-86a4-0d9fc2483383%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
