[Buildbot-devel] issues with buildbot

Chris Leishman chris at leishman.org
Tue Aug 30 07:19:22 UTC 2005

Hi all,

I'm in the process of setting up a new buildbot system for a large
project.  It's a great tool and I've got it mostly running now, but I
thought I'd give you some feedback on the few issues I've noticed.

1. Contrary to what I would have thought, the 'Force Build' doesn't
replace a build that is pending (due to changes with a stable timer), it
instead starts a build of HEAD independently -  and then the build of
the changed revision (usually the same) will begin immediately after.
This is a bit odd, and also is a problem in my setup where (for various
reasons) I assume the revision each build is based on is newer than the

2. The 'Stop Build' button sends a SIGKILL to the build process.  It
really should use SIGTERM so that the process can cleanup any temporary
files, locks or such.  It can still be followed by SIGKILL if it fails
to exit in a timely manner.

3. The PBChangeSource doesn't allow you to specify a prefix of more than
one directory - if you do it just treats it as an always failed match.

4. It seems that the output to the build step logs is overly buffered,
making it impossible to watch the build process output in anything close
to real time.

5. The ShellCommand build step doesn't allow you to set the description
via the init call parameters.  Maybe my python is bad, but I'm not sure
how to set it aside from here, since the steps are actually in the tuple
of s(step.ShellCommand, arg = x, arg2 = y, ...) - so there's no actually
instance of the object to set the description attribute on.  (In my
configuration I've created a subclass of ShellCommand that does
understand a description argument to init and sets the attribute from

6. (wishlist) In my environment I actually have only one supported
platform and hence only a single builder.  But I do have multiple build
trees of the same code (different released versions that are still
actively maintained).  It would be nice if the same master could manage
all the code branches (since the build process is identical).  It would
also be nice if the WaterFall display could show the status of all the
different build trees in the one page, rather than having to create a
separate html.WaterFall object using a different port for each.

7. (wishlist) This may be already possible, but it would be nice if the
builder could have access to the build output files easily.  My build
steps include archiving successful builds and making them available
to users, and it would be nice to include the build logs in the archive.


More information about the devel mailing list