In addition, there is still the possibility of Incredibuild to speed up builds...
On Mon, Sep 11, 2017 at 8:31 PM Chris Olivier <cjolivie...@gmail.com> wrote: > I would also prefer to throw more machines at it rather than restrict > builds. I think that we should revisit the load when CI is functioning > again for awhile and the backlog is caught up. > > > On Mon, Sep 11, 2017 at 8:01 PM Nan Zhu <zhunanmcg...@gmail.com> wrote: > >> +1 and recommend Jenkins-GitHub plugin with which committers/(accounts >> with assigned permissions) can trigger Jenkins build with >> >> "Test this please, Jenkins!" >> >> "Retest this please, Jenkins!" >> >> And accounts in the list can trigger build automatically when submitting >> a PR >> >> >> https://wiki.jenkins.io/plugins/servlet/mobile?contentId=37749162#content/view/37749162 >> >> Best, >> >> Nan >> ________________________________ >> From: workc...@gmail.com <workc...@gmail.com> on behalf of Tianqi Chen < >> tqc...@cs.washington.edu> >> Sent: Monday, September 11, 2017 7:54:05 PM >> To: dev@mxnet.incubator.apache.org >> Subject: Re: MXNet: Run PR builds on Apache Jenkins only after the commit >> is reviewed >> >> I agree that have the CI is useful, at least make sure that lint stage is >> done. >> >> Tianqi >> >> On Mon, Sep 11, 2017 at 7:49 PM, Hagay Lupesko <lupe...@gmail.com> wrote: >> >> > Build success or failure is a great feedback mechanism, of equal >> importance >> > to code review. Do we really want to delay it until another Dev gives a >> > thumbs up? It feels like a step backwards from automation. >> > >> > If our problem is resource constraint, can't we address it by throwing >> more >> > instances into the pool? >> > >> > On Sep 11, 2017 6:28 PM, "shiwen hu" <yajiedes...@gmail.com> wrote: >> > >> > > Jenkins can be set to automatically cancel old builds, but I'm not >> sure >> > if >> > > it's already been set >> > > >> > > 2017-09-12 9:19 GMT+08:00 Chris Olivier <cjolivie...@gmail.com>: >> > > >> > > > Is the load artificially high because there's such a backlog due to >> > other >> > > > reasons? Many may be triggering trivial changes to kick off another >> > build >> > > > attempt (I have). >> > > > >> > > > Do new PR changes actually stop the old build or do those go to >> > > completion? >> > > > I realize they show on the PR as a new build has started, but are >> the >> > old >> > > > builds/tests always interrupted? >> > > > >> > > > >> > > > On Mon, Sep 11, 2017 at 6:12 PM Naveen Swamy <mnnav...@gmail.com> >> > wrote: >> > > > >> > > > > +1 >> > > > > >> > > > > Even a small change in the PR is initiating a new build, I think >> this >> > > is >> > > > > needless and not serving any good purpose until a reviewer has >> looked >> > > > into >> > > > > the PR. This is also adding unnecessary load on the mxnet build >> > > pipeline >> > > > > and slaves. >> > > > > >> > > > > Thanks, Naveen >> > > > > >> > > > > >> > > > > On Mon, Sep 11, 2017 at 5:50 PM, Meghna Baijal < >> > > > meghnabaijal2...@gmail.com >> > > > > > >> > > > > wrote: >> > > > > >> > > > > > Hi All, >> > > > > > We would like to initiate a change in the way the PR builds are >> > being >> > > > > > triggered. At the moment, every time a Pull Request is created, >> a >> > > build >> > > > > > gets triggered on Jenkins. Additional builds also get triggered >> due >> > > to >> > > > > > changes to the same PR. >> > > > > > Too many PR builds leads to resource starvation and very long >> > queues >> > > > and >> > > > > > long build times. Hence we would like to add some checks where a >> > > human >> > > > > > reviewer manually marks it to something like “ok to build” >> before a >> > > PR >> > > > > > build is triggered. >> > > > > > >> > > > > > Do you think this approach would be helpful and we should move >> > > forward >> > > > > > with it? >> > > > > > >> > > > > > Thanks, >> > > > > > Meghna Baijal >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> >
