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 >
