Return-Path: X-Original-To: apmail-builds-archive@minotaur.apache.org Delivered-To: apmail-builds-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 79B07C3FA for ; Wed, 26 Nov 2014 10:12:59 +0000 (UTC) Received: (qmail 17873 invoked by uid 500); 26 Nov 2014 10:12:58 -0000 Delivered-To: apmail-builds-archive@apache.org Received: (qmail 17828 invoked by uid 500); 26 Nov 2014 10:12:58 -0000 Mailing-List: contact builds-help@apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: builds@apache.org Delivered-To: mailing list builds@apache.org Received: (qmail 17787 invoked by uid 99); 26 Nov 2014 10:12:58 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Nov 2014 10:12:58 +0000 Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id D460B1A037A for ; Wed, 26 Nov 2014 10:12:44 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id l18so3252955wgh.12 for ; Wed, 26 Nov 2014 02:12:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.60.45 with SMTP id e13mr3272244wjr.109.1416996772579; Wed, 26 Nov 2014 02:12:52 -0800 (PST) Received: by 10.194.138.69 with HTTP; Wed, 26 Nov 2014 02:12:52 -0800 (PST) Date: Wed, 26 Nov 2014 10:12:52 +0000 Message-ID: Subject: builds.apache.org suitability for Brooklyn integration tests From: Richard Downer To: builds@apache.org Content-Type: text/plain; charset=UTF-8 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)