[Buildbot-devel] Waterfall page enhancements (was: Add support for robots.txt)

[Brian Warner]

> Do you want me to redo the patch, or will you rework it yourself?

I'll do it.. I should start thinking about making the whole Waterfall thing
more flexible anyway.

So, the goal for that is to make buildbot.status.html contain a bunch of
separate status-bearing pages, which you can piece together any way you like.
There are a number of built-in object-specific ones (basically everything
that exists now *other* than the main Waterfall page, like the "everything
there is to know about Build #5 of builder foo", and the "Change #27" page)..
these will all stick around but are basically invisible, they are always
available somewhere but it doesn't really matter where since they're only
linked to from the primary pages.

The Waterfall page is one view, but there are others that folks here have
suggested:

 a view with one column per Builder, which shows just the results of the most
 recent build. (alternatively one row per Builder, or some kind of
 sensibly-wrapped grid, the idea being to take up as little space as possible
 so you can see dozens of Builders at once)

 a chonological but text-based view, with one line of text per event, where
 events are either Changes or builds finishing. The text is colored according
 to the results of the build.

 a grid with one row per Change, one column per Builder, and all you care
 about is whether the Change resulted in a good build or not. Kind of
 chronological but more Change-focussed.

and then multiply those by a couple of modifiers:

 only show trunk builds: ignore builds of other branches, also ignore 'try'
 builds

 only show certain Builders, perhaps those in certain categories (or exclude
 certain ones)

 show steps, don't show steps

Plus a top-level index page that can point at all the other ones.

Now, how to stitch this all together? The Twisted web code works in terms of
"Resource" objects, arranged in a tree, where a URL path like foo/bar/baz
(coming from a full URL like http://example.org/foo/bar/baz) means to start
with the root object, call its getChild("foo") method which returns a second
Resource, call *that* objects' getChild("bar") method to get a third one,
call that one's getChild("baz") object to get the final Resource, then
finally invoke render() on the baz Resource to create the actual page.

So if we imagine a bunch of buildbot.status.html classes like
html.OneColumnPerBuilder and html.ChronologicalText and html.ChangeGrid (all
subclasses of Resource), then the master.cfg setup might look a bit like:

 s = html.WebStatus(http_port=8080)
 s.setRoot(html.IndexPage())
 s.addChild(html.ChronologicalText())
 c['status'].append(s)

In this case, the URl for the ChronologicalText page would be auto-generated,
and the IndexPage would give a fairly generic description of the buildbot and
the project and then have a list of potential status pages, including the
ChronologicalText page.

Alternatively, you could set up your own custom index page, and then add the
other status pages at specific named locations to match the URLs you use:

 myindex = open("index.html","r").read()
 s.setRoot(html.CustomIndex("text/html", myindex))
 s.addChild(html.ChronologicalText(), "chrontext")

There could also be a way to add those html.* classes to an existing
Nevow-based web site, although at the moment I can't think of how to set that
up cleanly.


thoughts? can the folks who want to customize the way their HTML pages look
think about how they might use this, or what other kinds of status pages
they'd want?

thanks,
 -Brian