Bitten Build Slave Configuration

When a build slave registers with a build master, it sends information about the machine the slave is running on, and what software it has available. The build master uses this information for matching the slave against target platform rules. While some of this information can be automatically discovered by the slave, other information may need to be configured explicitly. Also, a slave instance may want to override some of the automatically computed attributes, for example to enable cross-compilation.

There are three categories of information that can be configured for a slave:

os

Properties of the operating system

machine

Properties of the underlying hardware

packages

Various pieces of software, such as a language runtime, a library, etc.

Configuration File Format

For simple manual editing, the slave configuration file will be based on the “INI” file format known from Windows, which is also frequently used by Python applications and supported by Pythons´ ​ConfigParser module.

A configuration file is partitioned into named sections. There are two predefined sections named [machine] and [os]. If you supply them in your configuration file they should include the following sections.

[os]
name = linux
version = 2.6.17
family = posix

[machine]
name = grogan
processor = x86

There may be any number of additional sections, where each section corresponds to a software package. For example:

[dbxml]
version = 2.1.8

[python]
version = 2.3.5
path = /usr/bin/python2.3

The build slave sends this package information as part of the build initiation, which then might look like this:

  MSG 1 0 . 0 120
  Content-Type: application/beep+xml
  
  <register name="levi" maintainer="Christopher Lenz &lt;cmlenz@gmx.de&gt;">
    <platform>Power Macintosh</platform>
    <os family="posix" version="8.1.0">Darwin</os>
    <package name="dbxml" version="2.1.8" />
    <package name="python" version="2.3.5" path="/usr/bin/python23" />
  </register>
  END

These properties can then be used in a build configuration to match slaves against target platforms. For example, the following rule would match any slave providing ​Berkeley DB XML version 2.x:

  dbxml.version ~= /^2\.\d\.\d.*/

The properties are accessible in dotted notation, where the part before the dot is the package name, and the part after the dot is the name of the property.