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:
- clobber existing source tree
- check out client.mk
- download mozconfig
- apply patch
- configure
- 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.