WARNING:

This document is not complete yet. When this warning disappears, that will mean the document is ready.

The Subversion Build/Test Farm

$LastChangedDate$

We are designing a build/test farm for Subversion, to test portability more conveniently and consistently. We hope this will lead to fewer surprises at Release Candidate time.

This document describes the build farm. The intended audiences are:

Overview

We've tentatively decided to use BuildBot for build management software, in part because of its TryScheduler feature, which lets a developer ask the question "What would happen if I committed this patch right now?". It runs the unit test suite (across multiple build platforms) on the developer's current code, allowing her to make sure her changes will not break the tree when she finally commits them. The default setup, however, is to build a repository tree, usually trunk, or a release branch or tag.

BuildBot uses two terms, buildmaster and buildslave, that mean exactly what you think they do. There is typically one buildmaster, and multiple buildslaves. Most people will want to read about buildslave configuration, which tells how to set up a buildslave client. Buildmaster setup is covered here, but is probably of interest only to the CollabNet administrators who run the buildmaster server.

Buildslave

  1. Install all the dependencies required to build Subversion from working copy source. That's outside the scope of this document, but see http://svn.collab.net/repos/svn/trunk/INSTALL for details.

  2. Create a user buildslave on your system. The buildslave client will use this user, instead of your regular development user. This is partly for security reasons, but also because part of the point of the build farm is to make sure things work in a relatively untweaked environment.

  3. Create a directory in ~buildslave/ to be the base directory for Subversion builds, hereinafter known as the "BASEDIR". For example, ~buildslave/subversion-builds/. The buildslave will touch nothing outside this directory.

  4. Write a script that checks out a copy of trunk (or whatever branch or tag you want to build), runs configure, make, make check, make davcheck, make svncheck, etc. Make sure the build works without manual intervention. Otherwise, it will not work when BuildBot attempts to do it automatically.

    We recommend having that script live in BASEDIR, and having it check out the working copy such that it creates a new subdirectory within BASEDIR.

  5. Obtain your slavename and password from the central administrator.

    Document exactly who to contact and how.

  6. Initialize the buildslave (the BuildBot docs call this "creating" the buildslave):

       buildbot slave BASEDIR MASTERHOST:PORT SLAVENAME PASSWORD

  7. Fill in your "hostinfo files", so other people can see the environment your builds run in, and can contact you if something appears to be wrong. BASEDIR/info/admin should contain your name and email address. This will be visible from the build status page; you can munge it to protect from spam address harvesters. BASEDIR/info/host should contain a description of the host: OS, version, memory size, CPU speed, versions of relevant libraries installed, and the version of the buildbot code which is running the buildslave.

    Give examples of these files.

    If you run many buildslaves, you may want to create a single ~buildslave/info file and share it among all the buildslaves with symlinks.

Buildmaster

BuildBot uses the usual Python installation mechanism, and depends on the TwistedMatrix library. If you happen to use Debian GNU/Linux, you can set these up very easily:

   # apt-get update
   # apt-get install python2.3-dev
   # apt-get install twisted

Just follow the instructions at http://buildbot.sourceforge.net/manual-0.7.0.html#Installation

...working here...

Trying out a change

...working here...

References