A build slave which is to run the Twisted test suite on a particular platform or in a particular configuration needs the following software:

  • Python
    • On Debian, the python-profiler package should also be installed.
    • On platforms where the Python headers are separated from the main Python package, these should also be installed (usually python-dev or python-devel).
  • A C compiler which can build Python extension modules (On POSIX, this usually means gcc; on Windows, some version of Visual Studio, depending on which version of Python is installed; most likely VS2008 aka VS9)
  • zope.interface (Debian package python-zope.interface)
  • On Windows, pywin32
  • Twisted - required by buildbot
  • BuildBot - only buildbot-slave is necessary
  • bazaar - sometimes packaged as bazaar-ng
  • Git (this is gradually replacing Bazaar)

As well as all (or as many as possible) of the libraries Twisted depends on:

OS Configuration

Unfortunately a few tests in Twisted's test suite will fail if certain guarantees are not made by the environment. For example, the multicast tests try to use the actual network stack to send multicast packets. Here are some things that are known about this:

  • For the multicast tests to pass, multicast packets must be routable over localhost.
    • On OS X, this means "Internet Sharing" must be disabled
    • Some Linux distributions have a default iptables rule to drop multicast traffic, or require an explicit iptables rule to allow it. For example, on Red Hat:
      -A INPUT --dest -j ACCEPT

Donating a Slave

What Buildslaves Do You Want?

Adding a buildslave is the first step to improving support on a new platform.

You are welcome to provide buildslaves for your favorite platforms. They will initially go in to the "unsupported" buildslave category. The only official requirement is that they maintain a high degree of uptime (see [ContinuousIntegration/FixYourDamnBuildSlave]).


If you wish to provide a buildslave for twisted, send the follwoing information to buildbot at twisted matrix dot com:

  1. Desired slave name. This will show up on Something like <name>-<machine-description>
  1. Password This is sent cleartext.
  1. Email address This is used to send mail messages when the slave disappears. It isn't visible.
  1. What builders you want set up.
    • what reactors are available/should be tested
    • path to the python executable, if it isn't the default python on the path.
  1. How many parallel builds you want allowed to run.

Upgrading Buildslaves

The OS running the build slave should in general *not* be upgraded; the point of having a CI system is to keep things working not to get new, better stuff. :) Now, if we hit an issue where a builder upgrade would be helpful, and the platform would has a feature we'd like to test, we will surely let you know, and *then* might be a good time to upgrade.

If you *are* going to be upgrading, you should send out a notification with each upgrade; shooting an email saying that there are new versions, and noting if there's a resulting build failure (and filing appropriate tickets), would be useful.

Upgrading the BuildBot slave software itself is usually fine, but it's always a good idea to check with us first.

Creating a Slave

A build slave is created with the buildslave create-slave command. This takes the master address, slave name, and slave password as arguments. The master address is Several other optional arguments are allowed. It is a good idea to specify a value of around 10 for --log-count to avoid unbounded log file growth. If there are special networking considerations, it may also be useful to specify a value for --keepalive. Other options generally aren't needed.

Last modified 8 years ago Last modified on 06/28/2013 09:38:18 AM