Quantcast

Is there an extension point just before a job is being built? Can we put a running job back into the waiting queue (without failing)?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Is there an extension point just before a job is being built? Can we put a running job back into the waiting queue (without failing)?

ThomasBrouwer
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 | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Is there an extension point just before a job is being built? Can we put a running job back into the waiting queue (without failing)?

Marek Gimza
Yes,  Have a look at the code for the Jenkins-Throttle plugin.

https://wiki.jenkins-ci.org/display/JENKINS/Throttle+Concurrent+Builds+Plugin


It extends "QueueTaskDispatcher" that is an abstract class with the methods 'canTake' and 'canRun' to allow your code to determine if the build in the queue is or not ready for building.

Kind Regards,
mgimza

On Wed, Aug 22, 2012 at 12:27 PM, ThomasBrouwer <[hidden email]> wrote:
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 | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Is there an extension point just before a job is being built? Can we put a running job back into the waiting queue (without failing)?

ThomasBrouwer
In reply to this post by ThomasBrouwer
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
Loading...