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 < > jenkins...@googlegroups.com <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 jenkinsci-users+unsubscr...@googlegroups.com. 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.
