Thanks! I've set up the job now. Thanks for your assistance. Richard.
On 18 December 2014 at 15:41, Andrew Bayer <andrew.ba...@gmail.com> wrote: > It's a label - "cloud-slave" will get you, well, a cloud slave. =) > > A. > > On Thu, Dec 18, 2014 at 7:06 AM, Richard Downer <rich...@apache.org> wrote: >> >> 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) >> >> >>
