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 03:32:45 GMT
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