[Python-Dev] buildbot

[Brian Warner]

> From: "Martin v. Löwis" <martin at v.loewis.de>
> 
> So at the moment, I'm quite happy with buildbot. My only wish is that
> it would do static pages, rather than being a web server. I set it up
> as a reverse proxy (so nobody knows what the port number is, but still).

As a bit of history, the buildbot's predecessor used static pages.. it just
dumped everything into HTML files any time something changed, and then I
pointed apache at the directory containing these files. By the time I started
the current Buildbot project, I had become familiar with Twisted, and elected
to use its built-in web server to provide status information. This makes it
much easier to implement things like the "Force Build" button, and allows the
same status-retrieving API to be used by all the different status-delivery
modules: web, IRC, email, PB. On the other hand, it makes it slightly harder
to merge the buildbot's web space into that of another web server (unless
that other web server also happens to be Twisted: the buildbot can run as a
twisted.web.distrib sub-server, which is how the Twisted buildbot presents
status).

The reverse proxy is a great way to improve the integration of the buildbot's
web pages into the rest of your site's. I'm hoping to improve the web-status
plugin to make it easier to change around the page layout from the buildbot
side, but even with that you'll want the reverse-proxy to remove the
port-number from the URL.

I should mention a feature that you might find useful: you can add some query
arguments to the top-level Waterfall page's URL to restrict the set of
Builders that are displayed. If you append "?show=full-2.3", you'll wind up
with a waterfall display that only contains the "full-2.3" Builder's column.
Appending "?show=full-2.3&show=full-2.4" will show two columns, etc. You can
also create multiple Waterfall instances, each with a different set of
"categories", and use that to manage the complexity of displaying status for
lots of Builders. (with the current release these multiple Waterfalls must
all listen on different TCP ports, unfortunately, but you can always hide
this with the reverse-proxy's URL mapping).

So you could have one page that shows *all* the builders, and another set of
pages that only show specific ones (perhaps one primary builder for each
architecture). If the reverse-proxy or some sort of Apache URL-rewriting
allows you to add query parameters to the target URLs, you might be able to
hide these filtered views behind simple-looking status URLs.

It's not the greatest solution, but it might let you add more Builders
without making the display unworkably complex.

cheers,
 -Brian