[Buildbot-devel] Small bugs and feedback.

Benoit Sigoure tsuna at lrde.epita.fr
Fri Nov 17 11:01:23 UTC 2006

Hello folks,

I've started to use the BuildBot two weeks ago and I must admit that it's by far
the best tool I've ever seen for setting up buildfarms.

So far I noticed two small bugs which I wanted to report along with some

The first bug is that when one changes the value of c['projectName'], sending a
SIGHUP to the buildmaster isn't enough to properly "refresh" the waterfall: the
name of the projects is properly updated in the top-left corner of the page as
well as in the bottom of the page but not in the <title> (which requires a

Second bug (maybe in the svn_buildbot_hook.py) is that file names are truncated
(the first 2 chars are missing) eg:
Changed files:

My feedback:
The BuildBot is by far the most complete tool I've seen so far and is highly
configurable. Although the Users' Manual is very complete and well written, I
must admit that the BuildBot is rather hard to set up. You need to read almost
the entire manual. Maybe a short "quick setup -- HOWTO" would be a good thing?
I say this because when you want things to get up and running, it's slightly
annoying to gather the information you need, especially when it's scattered
throughout the manual. A typical example of how to set up the BuildBot with SVN
for a standard project (probably using the autotools?) would have been
For instance I still can't get it right with branches. Whenever I commit in a
branch, the buildbot recompiles the trunk.
Here's a part of my config:
import buildbot.changes.pb
c['sources'] = [buildbot.changes.pb.PBChangeSource()]

from buildbot.scheduler import AnyBranchScheduler
c['schedulers'] = []
c['schedulers'].append(AnyBranchScheduler(name="all", branch=None,

Also, although I really like the waterfall, the BuildBot lacks a more synthetic
summary of the status of all the builds. I've read in the user manual that
you're planning to make it up for this shortcoming but I just wanted to tell
you that I'd appreciate such a feature.
Actually, the best thing would be to be able to summarize the status of the
builds from several different buildmasters in a single page. My company is
developping many projects at the same time and we almost have one buildmaster /
project, it would be great to summarize the status of every builds in every
projects in a single page.

A final question:
Say I have a project "Foo" in its own repository which provides libfoo. Another
projects "app" which also has its own repository but that depends on libfoo. I
have a single buildmaster for both projects, "app" depends on "foo" (with the
scheduler.Dependent) so (if I get it right) once someone commits in "foo" it
will rebuild "app" using the new "foo" right? (the last step for "foo" is to
make install, the prefix being $HOME/local and "app" is configured to find the
files of "foo" in $HOME/local). What I noticed recently is that after a commit
in "foo" (the latest revision being now N), the buildbot tried to build "app"
revision N (which doesn't exist). This made me wonder whether the buildbot can
handle this can of design where the library and the application live in
different repositories?
Also I'm afraid that if the build of "foo" fails on say, windows, the whole
build of "foo" will be considered to have failed and "app" won't be rebuilt
with the new "foo" even though "foo" compiled on linux/osx (which entails that
the buildbot could have tried to rebuild "app" on linux and osx only).
Please correct me if I'm wrong :)

Anyway, thank you for this piece of software!

SIGOURE Benoit aka Tsuna
  /EPITA\ Promo 2008, LRDE

More information about the devel mailing list