Side note:
There is no "we". The below should say something like "I would like to
propose...", or "As part of my work at , I would like to
propose..." if it's coming from a team at your day job and you don't want
to hog all the glory :)
If it truly is "we", then the email should end with the "we"
I agree with Naveen. This is not a one-way door. We can refine and improve
the process as needed in the future.
I don't see this as case of who works harder (machines or humans). PRs
always involve a manual step. All we are saying is lets do the full
verification when someone reviewed the changes a
The current number of build steps for a successful build is around 30 each
requiring to run on a Jenkins executor(running on one instance), there are
plans to add additional tests(more build steps) for additional platforms
such as MAC OSX, IOT devices. I don't think it is practical nor necessary
to
Agreed with Bhavin.
One point which is being mentioned here is abort the previous build if a new
change is being published on same PR.
Which can be achievable by just changing the job configuration “Cancel build on
update” under Trigger setup.
https://github.com/jenkinsci/ghprb-plugin/issues/
Also +1 on this.
Haibin
On 9/12/17, 9:28 PM, "Chris Olivier" wrote:
+1 to this
On Tue, Sep 12, 2017 at 8:48 PM Bhavin Thaker
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
+1 to this
On Tue, Sep 12, 2017 at 8:48 PM Bhavin Thaker
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
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 p
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
wrote:
> +1
> I second only running sanity test (lint) until manual approval.
>
> On Tue, Sep 12, 2017 at 11:05 AM, Naveen Swamy wrote:
>
> > J
+1
I second only running sanity test (lint) until manual approval.
On Tue, Sep 12, 2017 at 11:05 AM, Naveen Swamy 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
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 me
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 wrote:
> Hi
>
>
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" wrote:
Hi All,
We woul
> >>
> > >> https://wiki.jenkins.io/plugins/servlet/mobile?
> > contentId=37749162#content/view/37749162
> > >>
> > >> Best,
> > >>
> > >> Nan
> > >>
> > >> From: workc...
___
> >> From: workc...@gmail.com on behalf of Tianqi Chen
> <
> >> tqc...@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 Jenkin
2
>>
>> Best,
>>
>> Nan
>>
>> From: workc...@gmail.com on behalf of Tianqi Chen <
>> tqc...@cs.washington.edu>
>> Sent: Monday, September 11, 2017 7:54:05 PM
>> To: dev@mxnet.incubator.apache.org
>&g
iki.jenkins.io/plugins/servlet/mobile?contentId=37749162#content/view/37749162
>
> Best,
>
> Nan
>
> From: workc...@gmail.com on behalf of Tianqi Chen <
> tqc...@cs.washington.edu>
> Sent: Monday, September 11, 2017 7:54:05 PM
> To:
ps://wiki.jenkins.io/plugins/servlet/mobile?contentId=37749162#content/view/37749162
Best,
Nan
From: workc...@gmail.com on behalf of Tianqi Chen
Sent: Monday, September 11, 2017 7:54:05 PM
To: dev@mxnet.incubator.apache.org
Subject: Re: MXNet: Run PR builds on
In addition, the recent CI congestion probably because of the windows CI
failure.
2017-09-12 10:54 GMT+08:00 Tianqi Chen :
> 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 wrote:
>
> > Build success
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 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
>
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
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 :
> 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
> atte
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
+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 Baij
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 an
24 matches
Mail list logo
