> > 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: <jenkin...@googlegroups.com <javascript:>> on behalf of nicolas de > loof <nicolas...@gmail.com <javascript:>> > Reply-To: "jenkin...@googlegroups.com <javascript:>" < > jenkin...@googlegroups.com <javascript:>> > Date: Thursday, March 10, 2016 at 1:46 AM > To: "jenkin...@googlegroups.com <javascript:>" <jenkin...@googlegroups.com > <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 <nicolas...@gmail.com > <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 <jgl...@cloudbees.com >> <javascript:>>: >> >>> On Wed, Mar 9, 2016 at 11:52 AM, Suckow, Thomas J >>> <thomas...@pnnl.gov <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 jenkinsci-de...@googlegroups.com <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 jenkinsci-de...@googlegroups.com <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 jenkinsci-dev+unsubscr...@googlegroups.com. 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.
