[Buildbot-devel] Running build slaves on the sourceforge compile farm

[Brian Warner]

> I'm looking at moving the setup to buildbot, as it looks like I can
> get it to work as I want a lot more easily (in particular being able to
> customise by subclassing rather than rewriting chunks will make it
> possible to keep my customisation separate).  And I'll get useful
> features like email notification which I don't currently get with
> tinderbox.

Great to hear! You should be aware that we don't have email notification of
build status yet, but with the internal changes from the last week it should
be a trivial matter to finally add that feature.

> I've read most of the information on the website, and it seems to me
> that the tricky part is going to be the build slaves on the compile farm
> hosts.

Wow. That environment is even more challenging than I thought. You're correct
that the normal slave arrangement isn't going to work. If you had more disk
space to work with, and the compile farm machines could talk to each other,
I'd suggest running both the slaves and the master within the farm, then use
proxy tricks to get the change notification in and the status information
out.

Yeah, go with the proxy-buildslave idea. You'll need to write BuildSteps
which do things like 'ssh cf-shell.sf.net ssh ppc-osx1 make all', but
fortunately the stdout/exit-code reporting should work exactly the same. The
source checkout phase will be, uh, interesting, as the buildbot design
doesn't really expect to have slaves related in that fashion. You'll have to
create a special "source "Builder which does nothing but get the sources into
the shared directory, then fire an Interlock which the real Builders are
waiting upon. That will prevent the builds from running until the sources are
available. This isn't ideal, and will break when a second change comes along
while the builds are running (to prevent the "source" builder from updating
the sources before the real builders have finished compiling would require
some kind of bidirectional interlock.. it's possible that the
interlock/dependency split that I'm planning will handle this use case, but
I'm not sure). But if your builds tend to run faster than your changes take
place, it should probably work well enough.

And as you pointed out, the proxy-buildslave approach will mean you don't
have to install twisted (or even python) on the real buildslaves, just on the
proxies. (and you'll probably run all the proxies on the same host as the
buildmaster anyway).

The buildmaster will run on the external machine, of course, with Changes
coming into it via email (feeding messages into a Maildir is my preferred
technique). We used that approach for the Twisted buildbot for a few weeks
while our freshcvs notification was down.


If you get this running, please let me know: being able to use the multiple
architectures of the sourceforge compile farm is just the sort of thing the
BuildBot is made for. It's a pity that you have to go through such hoops. I'd
love it if the farm were more buildbot-friendly: having python+twisted in
/usr/lib/ on all machines and letting them make connections to some internal
machine where you could run a buildmaster would probably be enough.

good luck,
 -Brian