If I'm not mistaken, there's some support for latent slaves (workers) meaning they could be spawned on demand, this might be what you're looking for. Sorry, cannot give you manual links - typing from my phone.
As for shared drive - adding to what Randy said - if all your VMs are running on a single machine you can use shared folders, essentially making your host machine a server. Thanks, Vasily P.S. Randy, I hope you are well, missing the times we were talking frequently (among all things that was extremely valuable language practice) чт, 31 мая 2018 г., 20:28 Randy D. Smith <randydeansm...@gmail.com>: > I've been waiting for someone more knowledgeable to respond to you, but > I've seen nothing yet... and I know that feeling where you're trying to > make progress but can't get over a hump, so let me suggest one possibility > to you for one piece of your problem. > > I, too, like the idea of splitting builds and tests. We do the following: > - Builds do their thing, then store there results in a "known place" > (NFS-mounted share drive, in our case), then Trigger the test runs (see > http://docs.buildbot.net/latest/manual/cfg-schedulers.html#sched-Triggerable > ); > - Tests then start-up, pull in the newly-built stuff, and test away. > > There are lots more ways to do this, I'm sure... but this simple approach > fits well with the idea that we want to archive our build results anyway... > > > Sorry, can't help you with the VM spin-up, because our testing requires > physical systems (quite separate, distinct, and *way *more diverse than > our build systems!). Hopefully someone else can share some insights there. > Bottom line, I think the answer to your last question should be "Yes!" > -- > RDS > > > On Tue, May 29, 2018 at 11:39 PM, honas grael <honasgraeym...@gmail.com> > wrote: > >> Hello, I am not sure if I managed to send this to the mailing list >> before. If I have my apologies for asking again. I have asked it on SO >> <https://stackoverflow.com/questions/50592498/separating-buildbot-build-machines-from-test-machines> >> >> I am new to using buildbot, I have figured out how to get the buildmaster >> and a couple of build workers running, in a setup much like below >> [image: buildbot_deploy.png] >> >> Essentially the build master polls the mercurial repo for changes and >> then tasks the build workers to do a build as per the build steps. Each of >> these is a separate windows Virtual Machine(VM). The bits with a green tick >> I think I've got a handle on. >> >> I would like to deploy the built applications onto separate VMs for >> testing. Basically the Worker VMs that do the build should not run tests. >> >> I guess the first question is how can I split build from test execution? >> >> Is there a way for the worker VM to transfer the built application (and >> any supporting files) as well as all the appropriate tests to one or more >> test VMs so that all the tests can be run on a different VM? >> >> In addition would it be possible for the Buildbot Worker to: >> >> - Spin up a test VM >> - Transfer all the files (application and tests) to the test VM >> - Trigger the running of the tests in that target test VM. >> >> *Note: The test VM would already be pre-configured with the appropriate >> OS, and relevant setup, so no need to create the test VM each time. Also >> the test VM would shut-itself down once the tests have all been run. So no >> need for the Worker VM to check-up later.* >> >> I've read that Buildbot supports libvirt, but I am not familiar with >> libvirt, or how to use it. I do have some experience with python though. >> >> Can I achieve all this using buildbot? >> Regards >> >> _______________________________________________ >> users mailing list >> users@buildbot.net >> https://lists.buildbot.net/mailman/listinfo/users >> > > _______________________________________________ > users mailing list > users@buildbot.net > https://lists.buildbot.net/mailman/listinfo/users
_______________________________________________ users mailing list users@buildbot.net https://lists.buildbot.net/mailman/listinfo/users
