There was no further off-list discussion or conclusion here. Cordova project ended up giving up the idea of running our tests using Apache Jenkins CI.
We setup our own on Azure[1] and using the Github PR builder plugin which does can use github comments [2] to indicate status and does not require any extra access to Github which is controlled by Apache. [1] http://cordova-ci.cloudapp.net:8080/ [2] https://github.com/apache/cordova-plugin-file-transfer/pull/146#issuecomment-221606884 Thanks, Nikhil On 5/20/16, 1:43 AM, "Michael Dürig" <mdue...@apache.org> wrote: Hi, Could you please update this thread with what was the outcome of any off-list discussion? I'm asking as we (the Jackrabbit PMC) might have similar requirements for our Oak sub-project. In particular we might be interested in self added slaves so the hardware requirements for our tests could be met. Michael On 8.4.16 11:26 , Nikhil Khandelwal wrote: > Hi David, Daniel, Andrew, Jfarrell, > I would like propose we meet online on google > hangouts/skype/slack/IRC/hipchat to discuss the range of solutions presented > here. There is a bunch of discussion back and forth, but we are blocked now > and would like to make more progress here. I can send out a poll to find a > suitable time for us to meet next week to move this further. > > It's critical for our project to have PR related testing. We support multiple > major platforms include Android, iOS, Windows, Windows phone, OS X and hence, > testing matrix and hardware is complicated - travis CI & appveyor are not > sufficient. > > We have over 300 PRs open (s.apache.org/cordovaPulls) in over 40 repos that > our project manages. Our ability to automate testing is critical for our long > term success and management of the high volume of issues and community > engagement. We have something working with Apache buildbot here: > ci.cordova.io but it only does post-commit test runs. They have proved to be > less effective than pull request and do not make the PR contributor > accountable for breaks. Hence, we want to implement PR based testing now > using Jenkins. > > Thanks for your time and help - we really appreciate it. > > Thanks, > Nikhil > > -----Original Message----- > From: Sarangan Rajamanickam > Sent: Tuesday, April 5, 2016 10:46 AM > To: builds@apache.org; Nikhil Khandelwal <nikhi...@microsoft.com> > Cc: jfarr...@apache.org; Daniel Takamori <p...@apache.org>; andrew bayer > <aba...@apache.org> > Subject: RE: Self-Adding Jenkins Build Machines > > Hi David, > > Please find the responses below: > > 1. Who is providing the machines? How many? Who will have access? (physical > and logical) Microsoft will be providing the slaves (One Windows 10 machine & > One Mac OS machine) mentioned. Microsoft Cordova committers will be having > access to these machines. > > 2. What access will the ASF have? > ASF will not have access to these machines. > > 3. What's the agreement behind providing the machines? > These machines will be used for running the CI builds for Apache cordova > project in a periodic basis and also for each PR (and the results will be > updated in PR) > > 4. Please let us know if you have any more questions. Also, I would like to > mention the fact that a similar setup (Master Apache Machine & Slave > Microsoft Machines) is in existence with the buildbot setup. > Could you please let us know if there is any difference between allowing > buildbot slaves and Jenkins slave? > > Regards > Sarangan Rajamanickam > -----Original Message----- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Wednesday, March 30, 2016 9:35 PM > To: Nikhil Khandelwal <nikhi...@microsoft.com> > Cc: builds@apache.org; jfarr...@apache.org; Daniel Takamori > <p...@apache.org>; andrew bayer <aba...@apache.org> > Subject: Re: Self-Adding Jenkins Build Machines > > I apologize for the lag. > > So, I guess I'd like to understand a few things. > Who is providing the machines? How many? Who will have access? > (physical and logical) > What access will the ASF have? > What's the agreement behind providing the machines. > > Historically we've resisted a single project plugging in dedicated resources > that can only be used by that specific project. > > --David > > On Mon, Mar 21, 2016 at 6:00 PM, Nikhil Khandelwal <nikhi...@microsoft.com> > wrote: >> Hi David, Daniel, Jake, >> How can we move this discussion forward? We have great ideas on how to >> improve testability of our project and manage the high volume of pull >> requests that we receive. However, determining the next steps here are >> critical to move forward. >> >> As Dmitry mentioned below, would a meeting be appropriate to discuss the >> merits of each approach you suggested below? >> >> Thanks, >> Nikhil >> >> -----Original Message----- >> From: Dmitry Blotsky [mailto:dblot...@microsoft.com] >> Sent: Tuesday, March 15, 2016 6:09 PM >> To: builds@apache.org >> Cc: David Nalley <da...@gnsa.us>; jfarr...@apache.org; Daniel Takamori >> <p...@apache.org> >> Subject: RE: Self-Adding Jenkins Build Machines >> >> Hi David, Daniel, Jake, >> >> Friendly ping re: joining our own machines to the ASF Jenkins, similar to >> how we connected them to the ASF Buildbot. We're working on major >> improvements to Cordova's CI process, and we'd just like to know if this >> scenario is at all possible, even if in the future. We just want to avoid >> carrying out work only to find out that this won't be possible. >> >> We're also willing to help out with any of the work that needs to be done to >> enable this process, if it's indeed possible. And if you guys would prefer a >> higher bandwidth discussion, we're available on the Infra Hipchat and we can >> even set up a meeting on Skype or Hangouts. >> >> Again, thank you all very much for your consideration and efforts to >> accommodate our scenario. >> >> Kindly, >> Dmitry >> >> -----Original Message----- >> From: Dmitry Blotsky [mailto:dblot...@microsoft.com] >> Sent: Friday, March 11, 2016 2:53 PM >> To: builds@apache.org; jfarr...@apache.org >> Cc: David Nalley <da...@gnsa.us> >> Subject: RE: Self-Adding Jenkins Build Machines >> >> 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 >>>
