On 10.10.17 18:04, Jim Rowan wrote: > I think you’re already on the right track. Sounds to me like you need to > write new latentWorker implementations for these other two situations. > http://buildbot.readthedocs.io/en/latest/manual/customization.html?highlight=latent#writing-a-new-latent-worker-implementation
Ah, there's even documentation specifically for writing your own latent workers. Excellent! > Given that you can script the process of establishing the desired build > environment, it shouldn’t be too much work; it amounts to triggering that > script. In your Mac case, you might want to think about what the “delete > user / recreate user” actually accomplishes, and do those items more > directly, perhaps inside the build recipe. You might be able to get away > with a normal long-running worker and avoid writing the new latentWorker > class. In the windows case, you’d probably put the worker into the VM > image, and your work amounts to simply starting up the VM. But, in the Windows case of the worker being installed in the VM image I start, it would still need to be a latent worker, right? Buildbot wouldn't schedule a build on a worker it can't connect to (because it's not running, when the VM is not running), or would it? > Sure, depending on exactly what you mean by “outside" … that implies that > your steps will have to reach “inside” in order to execute in the correct > context. If “outside” simply means a different WorkDir, that’s easy. If > it means “operate as a different userid”, you’d have to wrap every step in > sudo(), and it will get complex quickly. With outside I was thinking of something like: running the worker on the OS instance that runs Virtualbox, and it would trigger the build inside the VirtualBox VM over SSH/RemoteDesktop/... That way, the worker could be always running, even if the VM where the build happens is not. The problem is, this works OK enough if its "ssh ... make all" instead of "make all" for "command" build steps, but I can no longer use all the other nice buildsteps like: buildbot.steps.source.mercurial.Mercurial Because, they work on the local filesystem where the worker is running. I can't run that over SSH/Remotedesktop. Or can I? The same with many of the other buildsteps: FileUpload, MakeDirectory, ... If I use all these convenient abstractions, then I can't comfortably run a worker "outside". Yours, Damiano _______________________________________________ users mailing list [email protected] https://lists.buildbot.net/mailman/listinfo/users
