So are engineers. On Mon, Sep 11, 2017 at 8:35 PM shiwen hu <yajiedes...@gmail.com> wrote:
> Incredibuild is expensive > > 2017-09-12 11:32 GMT+08:00 Chris Olivier <cjolivie...@gmail.com>: > > > 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 > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > > > >
