The QueueTaskDispatcher has some problems as described in my first post. I 
need an extension point that is run when we already know there is an 
execution slot available for the job, giving us a last chance to put the 
job back into the queue.
If this does not exist, I need to find some way of telling a running job: 
put me back into the queue and run me later.

Thanks anyways for your reply!
Thomas

Op woensdag 22 augustus 2012 17:27:52 UTC+1 schreef ThomasBrouwer het 
volgende:
>
> Hi!
>
> I was wondering whether there is an extension point that, just before 
> building the job, lets you decide to put it back into the queue. 
> Also, is there a way of stopping a running job and put it back into the 
> queue, without the job passing/failing/etc? So it should just silently go 
> back into the queue from running.
>
> Currently I am using the QueueTaskDispatcher extension point, but the 
> problem with this is that it gets called once for every execution slot set 
> up in the entire Jenkins server, and my code should really only run once 
> (as in, run the code, and if it passes it should always get an execution 
> slot immediately, and if it fails simply goes back into the queue).
>
> A little context:
> I am making a plugin that allows you to acquire resources (similar to the 
> Exclusion plugin), but allows you to specify multiple resources of the same 
> type by adding them to a category. So we could have a category category_1, 
> with labels label_1 and label_2. Then a job can specify that it needs a 
> label from category_1 (and it can say it needs multiple categories too), 
> and then it might get label_1 allocated (as an environmental variable). 
> Currently I do this allocation in the QueueTaskDispatcher class, but if its 
> functions get called four times it means four labels are allocated rather 
> than one. Normally one would do that in a build step, just like the 
> Exclusion plugin, but we don't want a job to take up an execution slot 
> while waiting for a resource to become available. This could be solved by 
> answering my second question though, as I could then just put the job back 
> into the queue if it turns out the resource(s) is/are not available.
>
> Thanks for helping! :)
> Thomas Brouwer
>

Reply via email to