Certain URLs are “magic”, and the pages they serve are created by code in various classes in the buildbot.status.web package instead of being read from disk. The most common way to access these pages is for the buildmaster admin to write or modify the index.html page to contain links to them. Of course other project web pages can contain links to these buildbot pages as well.
Many pages can be modified by adding query arguments to the URL. For example, a page which shows the results of the most recent build normally does this for all builders at once. But by appending “?builder=i386” to the end of the URL, the page will show only the results for the “i386” builder. When used in this way, you can add multiple “builder=” arguments to see multiple builders. Remembering that URL query arguments are separated from each other with ampersands, a URL that ends in “?builder=i386&builder=ppc” would show builds for just those two Builders.
branch= query argument can be used on some pages. This
filters the information displayed by that page down to only the builds
or changes which involved the given branch. Use
reference the trunk: if you aren't intentionally using branches,
you're probably using trunk. Multiple
branch= arguments can be
used to examine multiple branches at once (so appending
?branch=foo&branch=bar to the URL will show builds involving
either branch). No
branch= arguments means to show builds and
changes for all branches.
Some pages may include the Builder name or the build number in the main part of the URL itself. For example, a page that describes Build #7 of the “i386” builder would live at /builders/i386/builds/7.
The table below lists all of the internal pages and the URLs that can be used to access them.
By adding one or more “builder=” query arguments, the Waterfall is restricted to only showing information about the given Builders. By adding one or more “branch=” query arguments, the display is restricted to showing information about the given branches. In addition, adding one or more “category=” query arguments to the URL will limit the display to Builders that were defined with one of the given categories.
A 'show_events=true' query argument causes the display to include non-Build events, like slaves attaching and detaching, as well as reconfiguration events. 'show_events=false' hides these events. The default is to show them.
By adding the 'failures_only=true' query argument, the Waterfall is restricted to only showing information about the builders that are currently failing. A builder is considered failing if the last finished build was not successful, a step in the current build(s) is failing, or if the builder is offline.
arguments will control what interval of time is displayed. The default
is to show the latest events, but these can be used to look at earlier
periods in history. The
num_events= argument also provides a
limit on the size of the displayed page.
The Waterfall has references to resources many of the other portions
of the URL space: /builders for access to individual builds,
/changes for access to information about source code changes,
By adding one ore more “category=” arguments the grid will be restricted to revisions in those categories.
A “width=N” argument will limit the number of revisions shown to N, defaulting to 5.
A “branch=BRANCHNAME” argument will limit the grid to revisions on
This page also has a “rev_order=” query argument that
lets you change in what order revisions are shown.
Valid values are “asc” (ascending, oldest revision first)
and “desc” (descending, newest revision first).
It allows a developer to quickly see the status of each builder for the first build including his or her change. A green box means that the change succeeded for all the steps for a given builder. A red box means that the changed introduced a new regression on a builder. An orange box means that at least one of the test failed, but it was also failing in the previous build, so it is not possible to see if there was any regressions from this change. Finally a yellow box means that the test is in progress.
By adding one or more “builder=” query arguments, the Console view is restricted to only showing information about the given Builders. Adding a “repository=” argument will limit display to a given repository. By adding a “branch=” query argument, the display is restricted to showing information about the given branch. In addition, adding one or more “category=” query arguments to the URL will limit the display to Builders that were defined with one of the given categories.
By adding one or more “name=” query arguments to the URL, the console view is restricted to only showing changes made by the given users.
NOTE: To use this page, your buildbot.css file in public_html must be the one found in buildbot/status/web/extended.css.
The console view is still in development. At this moment by default the view
sorts revisions lexically, which can lead to odd behavior with non-integer
revisions (e.g., git), or with integer revisions of different length (e.g., 999
and 1000). It also has some issues with displaying multiple braches at the
same time. If you do have multiple branches, you should use the “branch=”
query argument. The
order_console_by_time option may help sorting
revisions, although it depends on the date being set correctly in each commit:
w = html.WebStatus(http_port=8080, order_console_by_time=True)
/json/helpfor detailed interactive documentation of the output formats for this view.
numbuilds=argument will control how many build lines are displayed (5 by default).
A “no_builders=1“ URL argument will omit the builders column. This is
useful if each buildslave is assigned to a large number of builders.
One or more
branch= arguments can be used to
restrict the list. In addition, a
numbuilds= argument will
control how many lines are displayed (20 by default).
/one_line_per_build, this page will also honor
There are also a set of web-status resources that are intended for use by other programs, rather than humans.
 Apparently this is the same way http://buildd.debian.org displays build status