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 >