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.ba...@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 <rich...@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) >>
