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
