The buildmaster and buildslaves run as a background daemon process, and thus have no output to show off. However, many of the status delivery plugins are a bit more photogenic.

Waterfall

The Waterfall display is a web page that shows a chronological log of events. Each Builder gets a separate column, and usually there is a Builder for each distinct platform (or major version of some component library). The most recent events appear at the top of the page, and older events appear below them.

Each Build is a set of events, starting with the yellow "start build" box, followed (above the starting box) by a checkout step of some sort, then other compile/test steps as necessary. The config file controls which steps are run for which builds.

Each step contains hyperlinks to generated logfiles. On the left hand side is a "Changes" column which contains links to pages that describe the version-control patches or revisions that triggered the build.

In this example, I have committed a change at 4:46pm. About 5 minutes later, two builds were started (a third was also triggered, but a semaphore-like Lock caused it to be stalled for a few minutes, to reduce load on an underpowered buildslave). Those builds started by using the version-control system to update a local source tree, then they performed a compile step. Next, they ran unit tests, of which 270 tests passed and 6 were skipped. The "tw2.5-py2.3" builder had some number of warnings, probably deprecation warnings complaining about constructs that are discouraged in python-2.5 . However, the test step was not configured to flag these warnings, so the step's box is green. One of the builders performed an additional step called "pyflakes", which is a fast static analysis tool for python code to detect redefined or undefined names. This tool discovered 7 redefinitions, and marked the step orange to indicate that these warnings are important enough to pay attention to.

Many sites have customized the CSS to make this page prettier.

IRC bot

The IRC status plugin can be configured to join a specific server and channel. Once it has connected, other users can direct queries to the buildbot to learn about current operations and retrieve the results of recent builds. If enabled, the IRC bot can be used to force a build to be started.

Some users have enhanced their buildbot to detect when a build has failed and actively insult the developer responsible. The developer who fixes the build gets to choose the insult used the next time.

Live Status Clients

The 'buildbot statusgui' command runs a rough graphical client which connects to the "status port" and presents a real-time display of what each Builder is doing. Any build steps that are currently running are shown, along with their ETA. The results of the most recent build are also displayed.

In this example, a library is being tested against various versions of Python. The "python2.4" build has just started. The current step is a Darcs checkout, which is expected to complete at 1:26am (in four seconds from now). The build as a whole is expected to complete at 1:27am (in 34 seconds from now). These ETA displays are continually updated as the various checkout/compile/test steps progress. The most recent builds of "python2.4" and "python2.5" were successful, however the most recent build of the "2.4-nocrypto" builder was massively unsuccessful, with 171 failing test cases.

Debug Tools

The 'buildbot debugclient' command launches a simple Gtk-based debug control panel, mostly of use to developers but also handy for buildbot admins. From here you can force a build to be triggered.