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 02:59:15 GMT
In addition, the recent CI congestion probably because of the windows CI
failure.

2017-09-12 10:54 GMT+08:00 Tianqi Chen <tqchen@cs.washington.edu>:

> 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