rhelmer’s blog

As many of you know by now, Ben Hearsum has been doing awesome work on Buildbot integration, such as:

* bonsai support
* publishing to tinderbox
* setup and administration of the seneca cluster

Now the awesomeness continues, as we’re working on a Buildbot “try” server to allow developers to upload patches that will generate one-off builds, without having to check that patch in. This is great for experimental builds for proof-of-concept type code, as well as making sure your patch will compile on our supported OS environments.

Ben is doing most of the real work here, and we’re working hard to document and publish details of our setup so others can benefit (and of course, help us out when we hit problems!). Brian Warner just launched Buildbot.net which looks much more useful to me than the old sourceforge page, so expect to see more HOWTOs appearing there in the near future.

Note that we’re actually not using the “buildbot try” support, but instead using “buildbot sendchange” (however it’s worth reading about “try”, because it clearly explains what we’re trying to do here). There are several reasons for this; one is that “buildbot try” assumes that Buildbot is able to check out directly from CVS (not through client.mk like we do), and it also assumes that developers have buildbot installed on their development machine and have direct access to the Buildbot server on a special Buildbot-specific port. Finally, “buildbot try” does not accept patches directly; it expects to be run in your checkout and generate an appropriate patch itself.

We could work around the client.mk problem, but the rest are a bigger deal; a lot of developers use different version control systems, and Mozilla is definitely not new to managing patches.

So, the shortest path to happiness seems to be:

* give developers access to a “patch upload” web interface, the version Ben put together looks like this:

* have a custom series of steps, which does:

1) clobber existing source tree
2) check out client.mk
3) download mozconfig
4) apply patch
5) configure
6) compile

* upload the build to somewhere useful; for now we’ll probably just keep it on the “try” server, on the same webserver that hosts the patch upload UI. Each “try” request gets a unique ID, so we can use that to link to an appropriate output directory.

What you’d see on the Buildbot server page is something like this (NOTE – I hacked up this image to show you an interesting scenario, but didn’t feel like waiting around for a real checkin to coincide with my “try” test.. so, the times not matching up 100% in the ETA section is OK)

The left-most column is who made the change (the one from coop is from the bonsaipoller, while the one from me is via the patch upload interface). The left-most build column is a normal build triggered by coop’s change, while the right-most is triggered by my change.

In Buildbot, each build column represents a “Builder”, behind which there can be one or more buildslaves (buildslaves are the actual hosts, similar to a tinderbox client). This means that you can have several simultaneous builds on the same column that are actually happening on different machines, and in fact you can share the same hosts between different columns!

When we actually have Windows and Mac buildslaves hooked up to this, you’ll probably see one column for each OS, but that’s it. We can add or remove hosts as needed behind that, and Buildbot will handle queuing of the incoming requests if all the available build machines are busy.

2 Comments »

Trackback This Post | Subscribe to the comments through RSS Feed