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 <kottm...@gmail.com> 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 <pllar...@amazon.de>
> 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" <meghnabaijal2...@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
> >
> >
> >
> >
> >
> >
> > 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
>

Reply via email to