> > Could also be interesting if you are shutting down Jenkins and don't wan't > to wait for a build to complete
use pipeline and then your builds will then mostly survive Jenkins restarts. Or there is a proprietary restart aborted builds <https://www.cloudbees.com/products/cloudbees-jenkins-platform/enterprise-edition/features/restart-aborted-builds-plugin> plugin that will restart builds that where aborted on Jenkins startup. On Thursday, March 10, 2016 at 7:09:41 PM UTC, Thomas Suckow wrote: > > It would be an interesting feature if a build could be returned to the > queue. I would actually like that in the case the slave disappeared during > the build, I've had that happen a couple times over the last few years. > Could also be interesting if you are shutting down jenkins and don't wan't > to wait for a build to complete you could abort it and return it to the > queue. > > I think in the race condition case, as long as only a handful make it into > the run state you won't be pounding the server saying "give me a slice." We > have some large (to us) matrix builds and it probably isn't good to have > 20-30 jobs all trying to get a cut of the pie. > > From: <[email protected] <javascript:>> on behalf of nicolas de > loof <[email protected] <javascript:>> > Reply-To: "[email protected] <javascript:>" < > [email protected] <javascript:>> > Date: Thursday, March 10, 2016 at 1:46 AM > To: "[email protected] <javascript:>" <[email protected] > <javascript:>> > Subject: Re: One-Shot Executors > > please see > https://github.com/jenkinsci/one-shot-executor-plugin/commit/86c632091391e3204432a8c7d1a18bb48b3a66e3 > > > basically, this on let the provisionner keep a task in the Queue when it > can determine it hasn't enough resources to run extra slaves. > this can be used to prevent overload, or allocate some extra physical > nodes. > > 2016-03-09 23:32 GMT+01:00 nicolas de loof <[email protected] > <javascript:>>: > >> " >> I do agree that certain issues should fail immediately (image not found). >> Certain other issues should perform exponential backoff (Cloud >> infrastructure down). Provisioning limits could be annoying though, would >> be interesting if they could be left in the queue until Jenkins side >> provisioning limits are not violated. I am not sure how to handle an >> environment like Kubernetes though where other entities may be utilizing >> resources and you have to "share". >> " >> >> This is something we have in mind. Provisioner could wait for available >> resources before it creates a Slave, leaving the task in the queue with a >> LabelAssignment waiting for matching executor. Would anyway need to let the >> Run start *then* create the slave, which means some race condition could >> appear and the required resources aren't available for this Slave to start >> even they were, few ms before - or we need some way to reserve resources on >> the infra, which then would significantly limit the available >> implementations. Maybe then we could cancel the Run, as we run early in >> it's lifecycle, and re-schedule it as a task in the Queue, claiming the Run >> never existed ? >> >> 2016-03-09 21:40 GMT+01:00 Jesse Glick <[email protected] >> <javascript:>>: >> >>> On Wed, Mar 9, 2016 at 11:52 AM, Suckow, Thomas J >>> <[email protected] <javascript:>> wrote: >>> > Certain other issues should perform exponential backoff (Cloud >>> > infrastructure down). >>> >>> Or just fail the build and the next one should work. >>> >>> > It could also handle the logic of some users wanting to configure >>> slaves on >>> > a per job basis. >>> >>> If you mean “configure Docker images on a per-job basis”, this is >>> addressed by both the Docker Custom Build Environment and Docker >>> Pipeline plugins, both of which ought to move toward using this new >>> infrastructure. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Jenkins Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3ycEVavhfm2Kuj5pOB5fkPF6vaOJfb6Zu-89y%2BQRm95g%40mail.gmail.com >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3DQNuogSJvuUMWR9RbjczW1fAd8pAJD9aa0Lk0H5aFwAQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3DQNuogSJvuUMWR9RbjczW1fAd8pAJD9aa0Lk0H5aFwAQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" 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-dev/f9057367-ba35-4e4a-8ff3-fe5aa9b85a4e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
