mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From shiwen hu <yajiedes...@gmail.com>
Subject Re: MXNet: Run PR builds on Apache Jenkins only after the commit is reviewed
Date Tue, 12 Sep 2017 03:35:29 GMT
Incredibuild is expensive

2017-09-12 11:32 GMT+08:00 Chris Olivier <cjolivier01@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 <cjolivier01@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 <zhunanmcgill@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: workcrow@gmail.com <workcrow@gmail.com> on behalf of Tianqi Chen
> <
> >> tqchen@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 <lupesko@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" <yajiedesign@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 <cjolivier01@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 <mnnaveen@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 <
> >> > > > meghnabaijal2017@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
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message