[Buildbot-devel] Buildbot at Loopt

[Ian Peters-Campbell]

Hey everyone,

I thought you might like to know, Loopt (www.loopt.com) is now using
Buildbot for our client builds.  We've got a single buildmaster running
under CentOS, managing builds for the Loopt client on 4 platforms and dozens
of handsets.  We're using Loopt for Android, Brew, iPhone, and J2ME projects
across several carriers (AT&T, T-Mobile, Sprint, MetroPCS, etc.)

Our system is using Buildbot both for continuous integration, doing quick
sanity builds after check-in, but also allows our teams to each have an IRC
chatroom for their project and order builds through there.  It hasn't been
up and online for too long, but so far people seem to like it a lot.

We're using Buildbot 0.7.9 with a few thousand lines of custom code.   The
major portions of custom code do the following:

- Took configuration out of master.cfg and put it into a buildbot.cfg and a
series of <project>.proj files, all of which are in YAML.  I then wrote a
parser which reads in the configuration dictionaries and creates the
buildbot objects (poller, schedulers, builders, factories, bots, email
notifiers, buildslves, etc.)  For me this has several advantages: it allows
people who don't know Python to modify and add projects and builds much more
easily, it vastly reduces duplication of information in configuration, and
generally makes the code cleaner (at least to my eye.)

- Wrote what I can only call a Factory factory, which creates, populates,
and returns a factory based on the configuration values of the individual
builders.  Again, this cuts down on a lot of duplicate code.

- Extended the IRC bot to take build properties on the force build line, so
users can now, for instance, say:
iPhoneBot: force build iPhone-release because I said so --conf=Debug

Basically when the force line is being parsed, I spin through the "reason"
portion of the line and strip out any words which are prepended with --.
These are then split into key/value pairs (if possible) and added to the
build's properties.  This allows us to have a single builder per code
branch, but order builds for individual handsets, pointing at a variety of
servers, turning debug on or off, etc.

- Added a HistoryTracker, which keeps track of which ordered (not CI) builds
were successful, and attaches the branch's SVN logs from the current head
back to the branch's last successfgul ordered build (though the bounds can
be modified through flags to the bot.)  This history is then attached to the
build's outgoing emails, so that our SVN history acts as an explicitly
passed set of raw release notes to QA, etc.

- Fleshed out the "passing" build type in the mail notifier, since the code
was mostly there already.  Since if we are doing a packaged (ordered) build
it goes to a wider audience, and since we don't care to notify the non-dev
portions of that audience if the build fails, we often only want the
notifier to fire off mail if the build succeeds.

- added defaults to getProperty calls

There are a few other tweaks, but that's the stuff that jumps to mind.  I
haven't patched any of this into the main code-base, but I hope to do some
of that over the next couple of weeks (at least the passing notifier and the
getProperty calls.)  I hope I'll have call to remain involved in the
Buildbot community in the future and that I'll be able to contribute some to
the march of progress.

Anyhow enough of my taking up your time, but I thought you might all like to
hear about another up-and-running Buildbot system :)

Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20090306/fbdcfc25/attachment.html>