Also +1 on this. Haibin
On 9/12/17, 9:28 PM, "Chris Olivier" <[email protected]> wrote: +1 to this On Tue, Sep 12, 2017 at 8:48 PM Bhavin Thaker <[email protected]> wrote: > My vote is to make the CI build and test process lightweight and efficient > and not involve a human to give a go-ahead for a PR build. > > There are multiple ways to engineer a stable and efficient CI system, > (already discussed on this email thread), including canceling previously > running build for a particular PR before invoking a new build, using > Incredibuild, adding more machines to CI, etc. > > In short, as we scale to many engineers working on MXNet around the globe > in different time-zones, precious human involvement should be minimal and > be used judiciously only for critical things like code-review and only > after sufficient amount of sanity build-tests have passed. > > Let the machines work harder for humans and not the other way around. > > Bhavin Thaker. > > On Tue, Sep 12, 2017 at 12:20 PM Chris Olivier <[email protected]> > wrote: > > > The majority of these iterations is to trigger a build on the broken CI > in > > hopes it will finally pass... > > > > On Tue, Sep 12, 2017 at 11:15 AM Madan Jampani <[email protected]> > > wrote: > > > > > +1 > > > I second only running sanity test (lint) until manual approval. > > > > > > On Tue, Sep 12, 2017 at 11:05 AM, Naveen Swamy <[email protected]> > > wrote: > > > > > > > Just to be clear, the proposal is not to remove the PR build. It's > only > > > to > > > > delay the PR build until a reviewer has looked at it and marks it > > > Approved > > > > or adds a Label to build. Once it's approved and PR build succeeds a > > > > reviewer/committer can see the build result and merge to the master. > > > > > > > > I don't mean to pick on the author of this PR(Chris), I am just using > > > this > > > > build to support my argument. > > > > https://builds.apache.org/view/Incubator%20Projects/job/ > > > > incubator-mxnet/view/change-requests/job/PR-7577/ > > > > This has gone through 74 iterations, I understand not all of them > are > > > due > > > > to changes and some of them are due to build instability and some > dummy > > > > commits to getting the PR build to pass. However, the PR has been > under > > > > review and changes being made for the last several days. I don't > think > > it > > > > warrants a build trigger for every new change. Each build on average > > > takes > > > > about 2 hours running on all platforms. > > > > > > > > Probably we can run a lean down version of the current PR build where > > we > > > > have sanity-test(lint)->build on linux(cpu)->unit test on linux(cpu) > ? > > > > > > > > > > > > Thanks, Naveen > > > > > > > > > > > > > > > > > > > > On Tue, Sep 12, 2017 at 4:27 AM, Joern Kottmann <[email protected]> > > > > wrote: > > > > > > > > > Not sure how it works with jenkins, but other CI serves can look at > > > > > the commit message and skip the CI run based on certain commands in > > > > > it. > > > > > > > > > > Might make sense for small changes such as documentation updates, > > half > > > > > done PRs, etc. > > > > > > > > > > Jörn > > > > > > > > > > On Tue, Sep 12, 2017 at 11:17 AM, Larroy, Pedro < > [email protected]> > > > > > wrote: > > > > > > Hi > > > > > > > > > > > > I would like to integrate our CI system for devices to make sure > > PRs > > > > > build on ARM / android etc. Who has admin rights on the repository > so > > > we > > > > > can install the necessary hooks to trigger our builds? > > > > > > > > > > > > > > > > > > Kind regards. > > > > > > -- > > > > > > > > > > > > Pedro > > > > > > > > > > > > On 12/09/17 02:50, "Meghna Baijal" <[email protected]> > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Amazon Development Center Germany GmbH > > > > > > Berlin - Dresden - Aachen > > > > > > main office: Krausenstr. 38, 10117 Berlin > > > > > > Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger > > > > > > Ust-ID: DE289237879 > > > > > > Eingetragen am Amtsgericht Charlottenburg HRB 149173 B > > > > > > > > > > > > > > >
