buildslave braindump
I was thinking today about the buildbot modifications I've been meaning to get around to for a while, and maybe this weekend during the twisted vsprint I'll be able to get something done on it.

The idea goes like this. At the moment, buildbot works on the principal of having a single buildmaster, that many buildslaves connect to. An example is twisted's own buildbot. If you *clicky* there, you'll see a column titled 'OS-X'. That column is shiny, my wonderful powermac that IBM was so nice to provide me. Shiny is running a buildslave, which connects to the buildmaster that twisted runs. Every so often someone will make a CVS commit, which updates the source code. The Buildbot will then trigger a series of builds, one of those builds is the OS-X buildslave's builds, which look like:

• Checkout Sourcecode
• Compile
• Cleanup
• Test default reactor
• cleanup
• Test Threadedselect reactor

This works great. tsreactor and defualtreactor get tested on a nice fast macintosh so that we know when someone's done something in a CVS commit that will break all twisted programs that run on that platform. The issue I want to look at is speed and robustness of the build process.

If I turn off my machine at home, the OS-X column on the buildbot page dies until I turn my machine back on and restart the buildslaves (I haven't got it starting by default on boot yet - need to figure that out).

The thing I want to try and achieve is make it possible for someone to type at a prompt

 foo@bar$ ./install-buildslave.sh
Creating buildbot user...
Password: 
Done
Checking library availablity...Done
Downloading latest buildbot source...Done
Creating buildslaves...Done
Installing startup scripts...Done
foo@bar$

so that it will be possible for someone who knows practically nothing about how buildbot works to install a buildslave. The other side of the coin is, I want the server to be able to cope with many slaves capable of fulfilling the same role, or better, figuring out which slaves are capable of what roles.

There's factors involved: gtkreactor requires gtk to be installed, wxreactor requires wx, python2.3 slave requires to have python2.3 installed. So libraries will have to be tested for existance, and the library version numbers checked.

Then there's the perks we can achieve. With 10 buildslaves instead of 1, we can run the different test batteries on different slaves. And only 2 in 10 machines have work to do, and the work is cut in half. If a machine goes down because that person goes on camp for a week (that was me two weeks ago) then practically nobody notices.

So what I want to achieve is:
multiple slaves per column on the buildmaster's web interface, and
a script for installing a slave that requires practically no user intervention.