[Buildbot-devel] buildbot-0.7.0 released

[Brian Warner]

After five months of effort, I've finally finished releasing buildbot-0.7.0,
which is now available on the sf.net download site:

 http://buildbot.sourceforge.net/

As usual, the release is signed with my GPG key (0x1514a7bd), and the tarball
checksums are as follows:

 md5: 4e7a0cf65573471f29a627a0faafc042  buildbot-0.7.0.tar.gz
sha1: 7ee1277865080db4b3347310e997ee840ff550af  buildbot-0.7.0.tar.gz

This release includes several major new features:

 build-on-branch: one Builder can handle multiple branches of the same project

 try: use the Buildbot to test out changes you haven't even committed yet

 Locks: prevent certain Steps or whole Builds from running at the same time

 Dependencies: only run some builds if others have successfully completed

 multiple buildslaves per Builder: adds redundancy and simple load-balancing


Locks and Dependencies have been split out of the earlier "Interlocks", which
are now gone. Build scheduling has been removed from the Build objects into a
new set of Scheduler classes, which enables new flexibility (running builds
in response to Changes, in response to other builds succeeding, in response
to other Buildbots succeeding, web sites changing [think upstream release
tracking], at certain times of day, etc).

Note that users upgrading from previous versions MUST make some changes to
your config file: you have to add a c['schedulers'] element or none of your
builders will get triggered, and you have to convert any c['interlocks'] into
the new forms. The user's manual has a complete description of these items,
including examples.

(also, if anyone was running buildbot code from CVS, and you're using
Subversion or Darcs in your builds, and you were using the new
build-on-branch feature: I changed the argument names to baseURL= and
defaultBranch= for consistency with the rest of the code, so you might have
to change your config files to match).

Release notes are attached below, and are highly encouraged reading.


Now that this (*way* overdue) release is out, I'll be able to pay a bit more
attention to some rough edges in the UI. In particular, the web status pages
need to be broken into pieces that can be shuffled around, so we can add
something other than the gigantic show-everything Waterfall page. The new
features make this even more important: for example, you probably don't want
the failure of a 'try' build to make it look like the tree is broken, so it
would be nice to have a separate status page that shows the results of the
most recent *trunk* builds, ignoring everything else. Also, using the
multiple-slaves-per-builder feature allows you to have multiple
builds-per-builder running at the same time, which will probably confuse the
Waterfall display.


Have a stigmergic day,
 -Brian


* Release 0.7.0 (24 Oct 2005)

** new features

*** new c['schedulers'] config-file element (REQUIRED)

The code which decides exactly *when* a build is performed has been massively
refactored, enabling much more flexible build scheduling. YOU MUST UPDATE
your master.cfg files to match: in general this will merely require you to
add an appropriate c['schedulers'] entry. Any old ".treeStableTime" settings
on the BuildFactory instances will now be ignored. The user's manual has
complete details with examples of how the new Scheduler classes work.

*** c['interlocks'] removed, Locks and Dependencies now separate items

The c['interlocks'] config element has been removed, and its functionality
replaced with two separate objects. Locks are used to tell the buildmaster
that certain Steps or Builds should not run at the same time as other Steps
or Builds (useful for test suites that require exclusive access to some
external resource: of course the real fix is to fix the tests, because
otherwise your developers will be suffering from the same limitations). The
Lock object is created in the config file and then referenced by a Step
specification tuple or by the 'locks' key of the Builder specification
dictionary. Locks come in two flavors: MasterLocks are buildmaster-wide,
while SlaveLocks are specific to a single buildslave.

When you want to have one Build run or not run depending upon whether some
other set of Builds have passed or failed, you use a special kind of
Scheduler defined in the scheduler.Dependent class. This scheduler watches an
upstream Scheduler for builds of a given source version to complete, and only
fires off its own Builders when all of the upstream's Builders have built
that version successfully.

Both features are fully documented in the user's manual.

*** 'buildbot try'

The 'try' feature has finally been added. There is some configuration
involved, both in the buildmaster config and on the developer's side, but
once in place this allows the developer to type 'buildbot try' in their
locally-modified tree and to be given a report of what would happen if their
changes were to be committed. This works by computing a (base revision,
patch) tuple that describes the developer's tree, sending that to the
buildmaster, then running a build with that source on a given set of
Builders. The 'buildbot try' tool then emits status messages until the builds
have finished.

'try' exists to allow developers to run cross-platform tests on their code
before committing it, reducing the chances they will inconvenience other
developers by breaking the build. The UI is still clunky, but expect it to
change and improve over the next few releases.

Instructions for developers who want to use 'try' (and the configuration
changes necessary to enable its use) are in the user's manual.

*** Build-On-Branch

When suitably configured, the buildbot can be used to build trees from a
variety of related branches. You can set up Schedulers to build a tree using
whichever branch was last changed, or users can request builds of specific
branches through IRC, the web page, or (eventually) the CLI 'buildbot force'
subcommand.

The IRC 'force' command now takes --branch and --revision arguments (not that
they always make sense). Likewise the HTML 'force build' button now has an
input field for branch and revision. Your build's source-checkout step must
be suitably configured to support this: for SVN it involves giving both a
base URL and a default branch. Other VC systems are configured differently.
The ChangeSource must also provide branch information: the 'buildbot
sendchange' command now takes a --branch argument to help hook script writers
accomplish this.

*** Multiple slaves per Builder

You can now attach multiple buildslaves to each Builder. This can provide
redundancy or primitive load-balancing among many machines equally capable of
running the build. To use this, define a key in the Builder specification
dictionary named 'slavenames' with a list of buildslave names (instead of the
usual 'slavename' that contains just a single slavename).

*** minor new features

The IRC and email status-reporting facilities now provide more specific URLs
for particular builds, in addition to the generic buildmaster home page. The
HTML per-build page now has more information.

The Twisted-specific test classes have been modified to match the argument
syntax preferred by Trial as of Twisted-2.1.0 and newer. The generic trial
steps are still suitable for the Trial that comes with older versions of
Twisted, but may produce deprecation warnings or errors when used with the
latest Trial.

** bugs fixed

DNotify, used by the maildir-watching ChangeSources, had problems on some
64-bit systems relating to signed-vs-unsigned constants and the DN_MULTISHOT
flag. A workaround was provided by Brad Hards.

The web status page should now be valid XHTML, thanks to a patch by Brad
Hards. The charset parameter is specified to be UTF-8, so VC comments,
builder names, etc, should probably all be in UTF-8 to be displayed properly.

** creeping version dependencies

The IRC 'force build' command now requires python2.3 (for the shlex.split
function).