Mailing-List: contact builds-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: builds@apache.org
Received-SPF: pass (nike.apache.org: domain of andrew.bayer@gmail.com
 designates 74.125.82.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABQFKi2h5dB99ZJ_pzdV_X5u=xwby5K5MQRrUt+sghW632v4dQ@mail.gmail.com>
References: 
 <CABQFKi2h5dB99ZJ_pzdV_X5u=xwby5K5MQRrUt+sghW632v4dQ@mail.gmail.com>
From: Andrew Bayer <andrew.bayer@gmail.com>
Date: Mon, 1 Dec 2014 09:15:30 -0800
Message-ID: 
 <CAPbPdOahhxR2Jg2p78f=CK7cRUVRbAGP8CX8uS9B43wXFvEPXA@mail.gmail.com>
Subject: Re: builds.apache.org suitability for Brooklyn integration tests
To: "builds@apache.org" <builds@apache.org>
Content-Type: multipart/alternative; boundary=089e016817e82b45a505092ac319

--089e016817e82b45a505092ac319
Content-Type: text/plain; charset=UTF-8

So long as you don't need root, yeah, go merrily along on the cloud slaves
- they're restricted to a single executor, so you can't bust anything else
running on the slave at the same time, and if you're worried that you'll
make disruptive changes to future builds, you can check the "Single-Use
Slaves" option in your job config - when run on a cloud-provisioned slave,
that'll result in the slave being taken offline and destroyed after your
build completes.

A.

On Wed, Nov 26, 2014 at 2:12 AM, Richard Downer <richard@apache.org> wrote:

> Hello builds@apache.org - and I assume that Andrew Bayer is somewhere
> behind this alias?
>
> I was at your talk at ApacheCon Europe last week and asked a question
> about if the Jenkins infrastructure would be able to manage the
> Brooklyn project's integration tests. I'd like to explore this in some
> more detail.
>
> Brooklyn's normal mode of operation is - amongst other things -
> installing and managing software. So its integration tests will be
> doing things like downloading Tomcat, installing it on the local
> machine by shelling out to bash, and starting it, where it would do
> things like open TCP network ports for listening. So it is doing a lot
> of work outside of the JVM sandbox. Repeat this for a couple of dozen
> types of software.
>
> Furthermore, if there's any issue with the code under test, it may not
> be able to clean up - in the worst case there would be processes left
> running, consuming memory, disk space and network ports.
>
> When Brooklyn entered the Incubator, we moved our unit tests and PR
> builder onto builds.apache.org, but we left the integration tests on
> other infrastructure as we assumed that the shared build slaves were
> not an appropriate place for "messy" tests like these. Instead, the
> infrastructure we use relies on cloud build slaves which are shutdown
> after the test run, therefore avoiding any cleanup issues.
>
> In the discussion at ApacheCon, you suggested that we could
> potentially restrict our integration test job to running on the cloud
> build slaves.
>
> What's the best way for us to move forward and run our integration
> tests on builds.apache.org?
>
> Thanks,
>
> Richard
> Committer/PPMC @ Apache Brooklyn (incubating)
>

--089e016817e82b45a505092ac319--