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) > >> >
