The one that does the PR builds indeed.
Sent from my iPhone
On 09 Nov 2015, at 20:04, Daan Hoogland
mailto:daan.hoogl...@gmail.com>> wrote:
On Mon, Nov 9, 2015 at 6:00 PM, David Nalley
mailto:da...@gnsa.us>> wrote:
Which Jenkins?
preferably builds.a.o but whichever, no?
On Thu, Oct 29, 2
On Mon, Nov 9, 2015 at 6:00 PM, David Nalley wrote:
> Which Jenkins?
>
preferably builds.a.o but whichever, no?
> On Thu, Oct 29, 2015 at 10:11 AM, Remi Bergsma
> wrote:
> > Hi all,
> >
> > Just had a chat with Miguel.
> > He showed me that if we setup Github to notify Jenkins on “issue
> c
Which Jenkins?
On Thu, Oct 29, 2015 at 10:11 AM, Remi Bergsma
wrote:
> Hi all,
>
> Just had a chat with Miguel.
> He showed me that if we setup Github to notify Jenkins on “issue comments”
> (next to “pull requests” we have now) and then set a “trigger phrase” in
> Jenkins, we could automatically
All,
+1000 to this idea. bors [1] is an example of this type of system that works
well. It provides on-demand build and implements the project’s rules to merge
changes to the master/develop branch (e.g. an LGTM from two committers). In
addition to enforcing the project’s policies, it ensures
So Rajani, you suggest to remove the automatic trigger and leave that to
reviewer. Sound fine to me.
On Fri, Oct 30, 2015 at 7:35 AM, Rajani Karuturi wrote:
> Thats a good idea. I have seen other open source projects do it this way.
> (example: netty project)
> On demand build is a better way th
Thats a good idea. I have seen other open source projects do it this way.
(example: netty project)
On demand build is a better way than doing for every commit change.
especially when the code reviews are going on or there is WIP, its not
intended to do a build on every commit or update. (The commi
