[Buildbot-devel] buildbot-0.3.3 released

Brian Warner warner-buildbot at lothar.com
Thu May 22 00:50:17 UTC 2003


Buildbot-0.3.3 is now available from the sourceforge download page:
http://sourceforge.net/project/showfiles.php?group_id=73177 . The release is
signed with my GPG public key, available from
http://www.lothar.com/warner-gpg.html . The MD5 sum of the tarball is:

 a20b214d8b042a14a8b33e07cf455952  buildbot-0.3.3.tar.gz

This release fixes some bugs and adds a few small features. Keepalives were
added to help build slaves that live behind NAT boxes which time out idle TCP
sessions. A button was added off the waterfall page to let builds be started
by hand. A few changes were made to the way shell commands are executed in
the hopes of making a win32 build slave more likely to work.

Finally, the sample make-a-build-master scripts are actually included in the
tarball with this release. I seem to learn one new distutils thing with each
release :). At this point I think the tarball is no longer missing any files.

Complete NEWS contents for 0.3.3 are included below. Please send feedback to
the buildbot-devel mailing list.

Have a cross-platform day,
 -Brian


* Relase 0.3.3 (21 May 2003):

** packaging changes

*** include doc/examples in the release. Oops again.

** network changes

*** add keepalives to deal with NAT boxes

Some NAT boxes drop port mappings if the TCP connection looks idle for too
long (maybe 30 minutes?). Add application-level keepalives (dummy commands
sent from slave to master every 10 minutes) to appease the NAT box and keep
our connection alive. Enable this with --keepalive in the slave mktap
command line. Check the README for more details.

** UI changes

*** allow slaves to trigger any build that they host

Added an internal function to ask the buildmaster to start one of their
builds. Must be triggered with a debugger or manhole on the slave side for
now, will add a better UI later.

*** allow web page viewers to trigger any build

Added a button to the per-build page (linked by the build names on the third
row of the waterfall page) to allow viewers to manually trigger builds.
There is a field for them to indicate who they are and why they are
triggering the build. It is possible to abuse this, but for now the benefits
outweigh the damage that could be done (worst case, someone can make your
machine run builds continuously).

** generic buildprocess changes

*** don't queue multiple builds for offline slaves

If a slave is not online when a build is ready to run, that build is queued
so the slave will run it when it next connects. However, the buildmaster
used to queue every such build, so the poor slave machine would be subject
to tens or hundreds of builds in a row when they finally did come online.
The buildmaster has been changed to merge these multiple builds into a
single one.

*** bump ShellCommand default timeout to 20 minutes

Used for testing out the win32 twisted builder. I will probably revert this
in the next relese.

*** split args in ShellCommand ourselves instead of using /bin/sh

This should remove the need for /bin/sh on the slave side, improving the
chances that the buildslave can run on win32.

*** add configureEnv argument to Configure step, pass env dict to slave

Allows build processes to do things like 'CFLAGS=-O0 ./configure' without
using /bin/sh to set the environment variable

** Twisted buildprocess changes

*** warn instead of flunk the build when cReactor or qtreactor tests fail

These two always fail. For now, downgrade those failures to a warning
(orange box instead of red).

*** don't use 'clobber' on remote builds

Builds that run on remote machines (freebsd, OS-X) now use 'cvs update'
instead of clobbering their trees and doing a fresh checkout. The multiple
simultaneous CVS checkouts were causing a strain on Glyph's upstream
bandwidth.

*** use trial --testmodule instead of our own test-case-name grepper

The Twisted coding/testing convention has developers put 'test-case-name'
tags (emacs local variables, actually) in source files to indicate which
test cases should be run to exercise that code. Twisted's unit-test
framework just acquired an argument to look for these tags itself. Use that
instead of the extra FindUnitTestsForFiles build step we were doing before.
Removes a good bit of code from buildbot and into Twisted where it really
belongs.






More information about the devel mailing list