[users at bb.net] Running builds in a new machine instance every time

Damiano Boppart damiano+buildbotu at pep-security.net
Thu Oct 12 14:17:18 UTC 2017


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


More information about the users mailing list