mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Olivier <cjolivie...@gmail.com>
Subject Re: MXNet: Run PR builds on Apache Jenkins only after the commit is reviewed
Date Tue, 12 Sep 2017 04:27:25 GMT
So are engineers.

On Mon, Sep 11, 2017 at 8:35 PM shiwen hu <yajiedesign@gmail.com> wrote:

> 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