www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <rich...@apache.org>
Subject Re: builds.apache.org suitability for Brooklyn integration tests
Date Thu, 18 Dec 2014 15:06:00 GMT
Hi Andrew, all,

I've taken a look at setting this up - I've found most of the options
I need, but I'm not sure how to restrict the project to cloud slaves.
Is this done by means of a special label, or some other option? Is it
the "JClouds Instance Creation" option?

The project is "incubator-brooklyn-master-integration" if anybody
wants to poke it around.

Thanks
Richard.

On 1 December 2014 at 17:15, Andrew Bayer <andrew.bayer@gmail.com> wrote:
> 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)
>>

Mime
View raw message