[Buildbot-devel] Buildbot at Loopt

[Mark A. Grondona]

This is great.

I was just about to send an email asking if anyone had done some work
to allow multiple distinct projects to be easily integrated with a
BuildBot instance (preferably by the project maintainer and
not the buildbot maintainer) This sounds at least very close.

We have a bunch of small, separately maintained projects that 
all need to support the same basic range of platforms. Currently 
we use BuildBot as a package building system (not really its
intended use, I know, but it works out pretty well), and now
I'd like to allow projects to "subscribe" to continuous or
nightly builds. I'd like to set something up that is general
enough so that a project maintainer can just create config
file somewhere (possibly in an SVN repo that BuildBot is
watching) to subscribe their project to BuildBot services.
The could then trigger test builds nightly, by hand, or for
each commit.

It would also be nice if these same users could add their own
build slaves to the BuildBot instance, if they want to donate
a portion of their workstation's time to the greater good. ;-)

I'll be anxious to take a look at your changes, excellent!

mark



> 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=