Hi Jake, David,

Thank you, Jake, for clarifying the policy regarding a self-hosted Jenkins 
master. What about connecting our own build machines to the ASF Jenkins master, 
similar to what we did with Buildbot? David, Jake: is that option viable?

Kindly,
Dmitry

-----Original Message-----
From: Jake Farrell [mailto:jfarr...@apache.org] 
Sent: Wednesday, March 9, 2016 4:02 AM
To: builds@apache.org
Cc: Nikhil Khandelwal <nikhi...@microsoft.com>; Sarangan Rajamanickam 
<saraj...@microsoft.com>
Subject: Re: Self-Adding Jenkins Build Machines

Hey Dmitry
We do not open up any cross channels like that for externally controlled 
machines, you would have to use jenkins polling and wait for a change to occur 
and then trigger the build.

-Jake

On Tue, Mar 8, 2016 at 4:58 PM, Dmitry Blotsky <dblot...@microsoft.com>
wrote:

> Hi David,
>
> Thanks for your response! Re: our own build physical machines, we want 
> to use them because we expect to frequently change their environments 
> (cumbersome with Docker) and to have physical devices connected 
> (impossible with VMs). We've connected our own machines to the ASF 
> Buildbot with no problems before; is Jenkins a very different scenario 
> from Buildbot security-wise?
>
> To answer Alex's question: we want to run on builds.a.o because it 
> already has the ASF Git and GitHub repos hooked up to it. We've 
> definitely considered running our own CI like CloudStack does, but ASF 
> Git/GitHub integration is a major hurdle. We've had a lot of friction 
> setting this up in the past on Buildbot.
>
> David: if we do go the route of running our own Jenkins, how feasible 
> would it be to set up ASF Git and GitHub integration with it?
>
> Kindly,
> Dmitry
>
> -----Original Message-----
> From: David Nalley [mailto:da...@gnsa.us]
> Sent: Monday, March 7, 2016 9:00 PM
> To: builds@apache.org
> Cc: Nikhil Khandelwal <nikhi...@microsoft.com>; Sarangan Rajamanickam 
> < saraj...@microsoft.com>
> Subject: Re: Self-Adding Jenkins Build Machines
>
> Hi Dmitry,
>
> builds.a.o (like ci.a.o) is a relatively generic resources - we have
> ~20 Jenkins nodes and that is around to serve all of the ASF.
>
> In the past, we've created project-specific VMs or physical machines 
> when they've had unusual requirements. That's been pretty mixed though
> - in some cases we have had VMs or even entire physical machines go 
> unused for years despite them being absolutely necessary when requested.
>
> Technology has also moved along (or at least become more accessible), 
> and containers have become ubiquitous among developers - thus esoteric 
> build environments are pretty easy to fulfill with things like Docker 
> (builds.a.o has support for Docker).
>
> Additionally, at present our build slaves are trusted to the same 
> degree as out master - this means if we did accept these slaves, we'd 
> probably want exclusive access. We are also trying to standardize; and 
> having special snowflake nodes runs counter to that.
>
> I realize this means builds.a.o isn't a good fit for every project. In 
> fact a number of projects have needs we simply can't easily meet, and 
> they manage their own CI environment. (CloudStack, Traffic Server, 
> Ignite, etc)
>
> --David
>
> On Mon, Mar 7, 2016 at 7:05 PM, Dmitry Blotsky 
> <dblot...@microsoft.com>
> wrote:
> > Dear Infra folks,
> >
> > My name is Dmitry Blotsky and I'm one of the committers on the 
> > Apache
> Cordova project. I'm writing to please ask whether it's possible for 
> us to connect our own build machines to the Jenkins build machine 
> fleet. Our builds have a bunch of mobile-specific requirements 
> (emulators, devices,
> SDKs) and cross-platform requirements (OS X, Windows), and we already 
> have machines set up to handle them.
> >
> > Is there a process to do this? If not, could we help define one in 
> > any
> way?
> >
> > Thank you in advance for your help!
> >
> > Kindly,
> > Dmitry
>

Reply via email to