Build recipes are represented by XML documents. This page describes what commands are generally available in recipes, and any runtime configuration supported by these commands. Please note, though, that third-party packages can add additional commands, which would then be documented by that third party.
Contents
These are commands that are used without a namespace prefix.
Parse an XML file and send it to the master as a report with a given category. Use this command in conjunction with the <sh:pipe> or <x:transform> commands to send custom reports to the build master.
Name | Description |
---|---|
category | Category of the report (for example "test" or "coverage"). |
file | Path to the XML file containing the report data, relative to the project directory. |
Both parameters must be specified.
See also Report Formats.
Attach a file to the build or configuration as regular attachment. An already existing attachment on the same resource with same base filename will be replaced.
Note: Unless consistently building latest only, overwriting files on config level may lead to unexpected results.
Name | Description |
---|---|
file | Path to the file to attach, relative to the project directory. |
resource | The resource to attach the file to. Either 'build' (default) or 'config'. Optional. |
description | Attachment description. Optional. |
A bundle of generic tools that are not specific to any programming language or tool-chain.
Namespace: | http://bitten.edgewall.org/tools/sh |
---|---|
Common prefix: | sh |
Executes a program or script.
Name | Description |
---|---|
executable | The name of the executable program. |
file | Path to the script to execute, relative to the project directory |
output | Path to the output file |
args | Any arguments to pass to the executable or script |
dir | Directory to change to before executing the command |
timeout | Limits the runtime of this command to the specified number of seconds, after which it will be terminated. |
Either executable or file must be specified.
TODO
Pipes the content of a file through a program or script.
Name | Description |
---|---|
executable | The name of the executable program. |
file | Path to the script to execute, relative to the project directory |
input | Path to the input file |
output | Path to the output file |
args | Any arguments to pass to the executable or script |
dir | Directory to change to before executing the command |
Either executable or file must be specified.
TODO
These commands provide support for tools commonly used for development of C/C++ applications on Unix platforms, such as make.
Namespace: | http://bitten.edgewall.org/tools/c |
---|---|
Common prefix: | c |
Executes ths autotool autoreconf.
Name | Description |
---|---|
force | Consider all files obsolete |
install | Copy missing auxiliary files |
symlink | Install symbolic links instead of copies |
warnings | Report the warnings related to category (which can actually be a comma separated list) |
prepend_include | Prepend directories to search path |
include | Append directories to search path |
<c:autoreconf force="1" install="1" warnings="cross,syntax,error"/>
Runs the autoreconf tool in the base directory with the option: force, install and 3 warning categories active: cross,syntax,error. This is equivalent to:
autoreconf --force --install --warnings=cross,syntax,error
Executes a configure script as generated by Autoconf.
Name | Description |
---|---|
file | Name of the configure script (defaults to "configure") |
enable | List of features to enable, separated by spaces. |
disable | List of features to disable, separated by spaces. |
with | List of packages to include, separated by spaces. |
without | List of packages to exclude, separated by spaces. |
cflags | Value of the CFLAGS variable to pass to the script. |
cxxflags | Value of the CXXFLAGS variable to pass to the script. |
<c:configure enable="threadsafe" cflags="-O"/>
Runs the configure script in the base directory, enable the threadsafe feature, and passing -O as CFLAGS. This is equivalent to:
./configure --enable-threadsafe CFLAGS="-O"
Parameter with will expand any package found in slave configuration:
[mylib]
path = /path/to/mylib
Run gcov to extract coverage data where available.
Name | Description |
---|---|
include | List of glob patterns (separated by space) that specify which source files should be included in the coverage report |
exclude | List of glob patterns (separated by space) that specify which source files should be excluded from the coverage report |
prefix | Optional prefix name that is added to object files by the build system |
Executes a Makefile.
Name | Description |
---|---|
target | Name of the target to execute (defaults to "all") |
file | Path to the Makefile that should be used. |
keep-going | Whether make should try to continue even after encountering errors. |
jobs | Number of parallel jobs used by make. |
directory | Path of the directory in which make should be called. |
args | Any space separated arguments to pass to the makefile. Usually in the form: "parameter1=value1 parameter2=value2". |
<c:make target="compile" file="build/Makefile" />
Runs the target "compile" of the Makefile located in the sub-directory build.
<c:make target="compile" file="build/Makefile" directory="work" args="coverage=1" />
Same as previous but execute the command in the work directory and call the makefile with the command line argument coverage=1.
[make]
path = /path/to/(c|n)make
Report the test output generated by the CppUnit unit testing framework. The output from CppUnit must be in XML format and in already, specified by the file argument of this recipe.
Name | Description |
---|---|
file | Path to the cppunit XML output file. |
<sh:exec executable="run_unit_tests" output="test_results.xml" />
<c:cppunit file="test_results.xml" />
Runs the program run_unit_tests to gather the data output by CppUnit in the test_results.xml file and then reports it.
A bundle of recipe commands that support tools commonly used by Java projects.
Namespace: | http://bitten.edgewall.org/tools/java |
---|---|
Common prefix: | java |
Runs an Ant build.
Name | Description |
---|---|
file | Path of the build file, relative to the project source directory (default is build.xml). |
target | Name of the build target(s) to execute. |
args | Additional arguments to pass to Ant, separated by whitespace. |
keep_going | Tell Ant to continue even when errors are in encountered in the build. |
<java:ant target="compile" />
Executes the target compile of the build.xml buildfile at the top of the project source directory.
[ant]
home = /path/to/ant/dir
[java]
home = /path/to/java/dir
Extract code coverage data from a Cobertura XML file.
Name | Description |
---|---|
file | Path to the XML file generated by Cobertura |
<java:cobertura file="build/cobertura.xml" />
Reads the specifid XML file, extracts the coverage data, and builds a coverage report to be sent to the build master.
Extracts information about unit test results from a file in JUnit XML format.
Name | Description |
---|---|
file | Path to the JUnit XML test results file. This can include wildcards, in which case all the file matching the pattern will be included. |
srcdir | Path of the directory unit test sources. Used to link the test cases to files. |
The file attribute is required.
<java:junit file="build/tests/results/TEST-*.xml" srcdir="src/tests" />
Collects the test results from all files in the build/tests/results directory that match the pattern TEST-*.xml. Also, maps the class names in the results files to Java source files in the directory src/tests.
A bundle of recipe commands that support tools commonly used by Mono/.NET projects.
Namespace: | http://bitten.edgewall.org/tools/mono |
---|---|
Common prefix: | mono |
Extracts information about unit test results from a files in NUnit XML format.
Name | Description |
---|---|
file | Path to the NUnit XML test results file. This can include wildcards, in which case all the file matching the pattern will be included. |
The file attribute is required.
<mono:nunit file="build/tests/TestResult.xml" />
A bundle of recipe commands for PHP projects.
Namespace: | http://bitten.edgewall.org/tools/php |
---|---|
Common prefix: | php |
Runs a Phing build.
Name | Description |
---|---|
file | Path of the build file, relative to the project source directory (default is build.xml). |
target | Name of the build target(s) to execute. |
args | Additional arguments to pass to Phing, separated by whitespace. |
executable | Phing executable program (default is phing). |
<php:phing target="compile" />
Executes the target compile of the build.xml buildfile at the top of the project source directory.
Extracts information from PHPUnit test results recorded in an XML file.
Name | Description |
---|---|
file | Path to the XML results file, relative to the project source directory. |
<php:phpunit file="build/test-results.xml"/>
Extracts the test results from the XML file located at build/test-results.xml.
Extracts coverage information from Phing's code coverage task XML file or from PHPUnit coverage-clover XML file.
Name | Description |
---|---|
file | Path to the XML coverage file, relative to the project source directory. |
<php:coverage file="build/coverage.xml" />
A bundle of recipe commands that support tools commonly used by Python projects.
Namespace: | http://bitten.edgewall.org/tools/python |
---|---|
Common prefix: | python |
Executes a Python script.
Name | Description |
---|---|
file | Path of the script to execute, relative to the project source directory. |
module | Name of the Python module to execute. |
function | Name of the function in the Python module to run. Only works when also specifying the module attribute. |
args | Any arguments that should be passed to the script. |
output | Path to a file where any output by the script should be recorded. |
timeout | Limits the runtime of this command to the specified number of seconds, after which it will be terminated. |
Either file or module must be specified.
<python:exec module="pylint.lint" output="pylint-report.txt" args="myproj" />
Executes Pylint on the module/package myproj and stores the output into a file named pylint-report.txt.
[python]
path = /path/to/python
Executes a distutils script.
Name | Description |
---|---|
command | The name of the distutils command that should be run |
options | Additional options to pass to the command, separated by spaces |
timeout | Limits the runtime of this command to the specified number of seconds, after which it will be terminated. |
<python:distutils command="sdist" />
Instructs distutils to produce a source distribution.
<python:distutils command="unittest" options="
--xml-output build/test-results.xml
--coverage-summary build/test-coverage.txt
--coverage-dir build/coverage
--coverage-method trace"/>
Instructs distutils to run the unittest command (which is provided by Bitten), and passes the options needed to determine the output paths for test results and code coverage reports.
Option --coverage-method is one of trace, coverage or figleaf.
[python]
path = /path/to/python
Extracts information from unittest results recorded in an XML file.
Note: This report must be used in conjunction with the distutils command "unittest" that comes with Bitten.
Name | Description |
---|---|
file | Path to the XML results file, relative to the project source directory. |
<python:unittest file="build/test-results.xml"/>
Extracts the test results from the XML file located at build/test-results.xml.
Extracts coverage information recorded by the built-in Python module trace.py.
Name | Description |
---|---|
summary | Path to the summary file written by trace.py, relative to the project source directory. |
coverdir | Path to the directory containing the coverage files written by trace.py, relative to the project source directory. |
include | List of glob patterns (separated by space) that specify which Python file should be included in the coverage report |
exclude | List of glob patterns (separated by space) that specify which Python file should be excluded from the coverage report |
<python:trace summary="build/trace.out" coverdir="build/coverage" />
Extract data from a coverage.py run.
Name | Description |
---|---|
summary | Path to the summary file with coverage.py information, relative to the project source directory. |
coverdir | Path to the directory containing per-module coverage details, relative to the project source directory. |
include | List of glob patterns (separated by space) that specify which Python file should be included in the coverage report |
exclude | List of glob patterns (separated by space) that specify which Python file should be excluded from the coverage report |
<step id="test" description="Unittests with coverage.py information">
<python:distutils command="unittest"
options="--xml-output build/test-results.xml
--coverage-summary build/test-coverage.txt
--coverage-dir build/coverage
--coverage-method coverage" />
<python:unittest file="build/test-results.xml"/>
<python:coverage summary="build/test-coverage.txt"
coverdir="build/coverage"
include="mypackage/*" exclude="*/tests/*" />
</step>
Extracts coverage information recorded by Figleaf.
Name | Description |
---|---|
summary | Path to the summary file written by figleaf, relative to the project source directory. |
include | List of glob patterns (separated by space) that specify which Python file should be included in the coverage report |
exclude | List of glob patterns (separated by space) that specify which Python file should be excluded from the coverage report |
<step id="test" description="Unittests with Figleaf coverage">
<python:distutils command="unittest"
options="--xml-output build/test-results.xml
--coverage-summary build/test-coverage.txt
--coverage-dir build/coverage
--coverage-method figleaf" />
<python:unittest file="build/test-results.xml"/>
<python:figleaf summary="build/test-coverage.txt"
include="mypackage/*" exclude="*/tests/*" />
</step>
Extracts information from Pylint reports.
Name | Description |
---|---|
file | Path to the file containing the Pylint output, relative to the project source directory. |
<python:pylint file="build/pylint.out" />
A collection of recipe commands for working with the Subversion version control system. This commands are commonly used as the first step of a build recipe to actually pull the code that should be built from the repository.
Namespace: | http://bitten.edgewall.org/tools/svn |
---|---|
Common prefix: | svn |
Check out a working copy from a Subversion repository.
Name | Description |
---|---|
url | URL of the repository. |
path | The path inside the repository that should be checked out. You should normally set this to ${path} so that the path of the build configuration is used. |
revision | The revision that should be checked out. You should normally set this to ${revision} so that the revision of the build is used. |
dir | Path specifying which directory the sources should be checked out to (defaults to '.'). |
verbose | Whether to log the list of checked out files (defaults to False). |
shared_path | An optional shared directory to check the sources out in, which will be reused for each subsequent build. This is relative to the project directory, so for standard usage set it to something like ../trunk |
username | Username to pass for authentication (optional) |
password | Password to pass for authentication (optional) |
<svn:checkout url="http://svn.example.org/repos/myproject/"
path="${path}" revision="${revision}"/>
This checks out the a working copy into the current directory.
Download a file or directory from a Subversion repository. This is similar to performing a checkout, but will not include the meta-data Subversion uses to connect the local working copy to the repository (i.e. it does not include the .svn directories.)
Name | Description |
---|---|
url | URL of the repository. |
path | The path inside the repository that should be checked out. You should normally set this to ${path} so that the path of the build configuration is used. |
revision | The revision that should be checked out. You should normally set this to ${revision} so that the revision of the build is used. |
dir | Path specifying which directory the sources should be exported to (defaults to '.') |
username | Username to pass for authentication (optional) |
password | Password to pass for authentication (optional) |
<svn:export url="http://svn.example.org/repos/myproject/"
path="${path}" revision="${revision}"/>
This downloads the file or directory at ${path} from the Subversion repository at http://svn.example.org/repos/myproject/. Variables are used for the path and revision attributes so they are populated from the properties of the build and build configuration.
Update an existing working copy from a Subversion repository to a specific revision.
Name | Description |
---|---|
revision | The revision that should be checked out. You should normally set this to ${revision} so that the revision of the build is used. |
dir | Path specifying the directory containing the sources to be updated (defaults to '.') |
<svn:update revision="${revision}"/>
This updates the working copy in the current directory. The revision is specified as a variable so that it is populated from the properties of the build.
A collection of recipe commands for XML processing.
Namespace: | http://bitten.edgewall.org/tools/xml |
---|---|
Common prefix: | x |
Apply an XSLT stylesheet .
Note: This command requires either libxslt (with Python bindings) or, on Windows platforms, MSXML (version 3 or later) to be installed on the slave machine.
Name | Description |
---|---|
src | Path of the source XML file. |
dest | Path of the destition XML file. |
stylesheet | Path to the XSLT stylesheet file. |
All these are interpreted relative to the project source directory.
<x:transform src="src.xml" dest="dest.xml" stylesheet="util/convert.xsl" />
This applies the stylesheet in util/convert.xsl to the source file src.xml, and writes the resulting XML document to dest.xml.
A collection of recipe commands for working with Mercurial (hg) repositories.
Namespace: | http://bitten.edgewall.org/tools/hg |
---|---|
Common prefix: | hg |
Pull changesets and updates a local Mercurial repository.
As the command depends on a pre-existing repository, bitten-slave must be started with --build-dir= option for locating and working with the repository. Also, seeing no remote location can be specified the repository .hg/hgrc configuration file needs a [paths] default = .... location defined.
Name | Description |
---|---|
revision | The revision to update to (optional, defaults to tip). |
dir | Local subdirectory with repository (optional, defaults to '.'). |
Paths are interpreted relative to the project source directory.
<hg:pull revision="${revision}" dir="src" />
This updates the repository in src to the revision of the current build.
While the Recipe contains the instructions for how to build, configurations are used to determine what gets built and any runtime parameters used when building.
Contents
A target platform is something like 'NetBSD x86' or 'Win32 Java 1.4'.
Technically, a target platform is a named set of rules against which the properties of build slaves are matched. Each rule is a regular expression matching a particular slave property, such as the operating system or the processor. When a slave connects to the build master, it sends a registration message that includes information about the slave. A slave will only be sent builds for a given platform if the slave's properties satisfy all of the rules associated with that platform.
A rule's regular expression is matched against the value of the slave property using Python's re.match function so, for example, x86 will match a value of x86_64. Use ^x86$ to match only the value x86.
A build configuration must have at least one target platform assigned to it before it becomes fully active.
By default, the following properties are included:
family: | The basic type of operating system, typically “posix” for Unix-like systems and “nt” for Win32 systems. |
---|---|
os: | The name of the operating system (for example “Darwin”, “Linux” or “Windows”). |
version: | The operating system version. |
machine: | The hardware platform (for example “i686” or “Power Macintosh”). |
processor: | The processor architecture (for example “athlon” or “powerpc”). |
name: | The name of the slave. |
ipnr: | The IP address of the slave. |
Note that not all of these properties may be available for all platforms, depending on OS and Python version.
To set up a target platform, create rules that are checked against the properties of the slave. For example, a target platform that matches slave running Linux on x86 would look like this:
Property | Expression |
---|---|
os | ^Linux |
machine | ^[xi]d?86$ |
A target platform that matches any slaves running on Windows might look like this:
Property | Expression |
---|---|
family | ^nt$ |
The build master will request a build from at most one slave for every target platform. So, for example, if there are three slaves connected that are matching 'NetBSD x86', only one of them will perform the build of a specific revision. Slaves that match a particular target platform are treated as if they were completely interchangable.
If a slave connects that doesn't match any of the configured target platforms, the build master will reject its registration.
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. 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, like a language runtime or a library |
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.
The file is included at runtime using a slave command-line option:
bitten-slave -f config.ini
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 = Darwin
version = 8.1.0
family = posix
[machine]
name = levi
processor = Power Macintosh
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
Note: Options called name is not allowed in custom sections (will be skipped).
The build slave sends this package information as part of the build initiation, which when using verbose logging (bitten-slave -v) will display a debug message 'Sending slave configuration:' followed by:
<slave name="host.domain">
<platform processor="Power Macintosh">levi</platform>
<os version="8.1.0" family="posix">Darwin</os>
<package name="dbxml" version="2.1.8" />
<package name="python" version="2.3.5" path="/usr/bin/python23" />
</slave>
The name of the slave can only be set as command-line option:
bitten-slave --name=myhost
A number of commands support runtime settings using a slave configuration file. The example of python.path above is one such example, where all Python commands will use the specified executable for running commands.
The documentation for commands should include information about all runtime settings.
Defined properties can 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.
Property values can be interpolated into build recipes as well, so individual slaves can parameterize how their build is perfomed. For example, given the following build recipe excerpt:
<svn:checkout url="http://svn.example.org/repos/myproject/"
path="${repository.branch}" revision="${revision}"/>
Slaves may control which part of the repository is checked out and tested with a configuration file excerpt like this one:
[repository]
branch = /branches/0.3-testing
Default slave properties are also available for use in recipes:
<sh:exec executable="echo"
args="Slave: ${family} ${os} ${version} ${machine} ${processor}"/>
Additionally, environment variables are also interpolated, supporting the common notations of $VAR and ${VAR}.
<sh:exec executable="${PROGRAMFILES}/SomeDir/MyProg.exe" />
Authentication information can also be included in slave configuration file:
[authentication]
username = myusername
password = mypassword
The authentication information will be removed as soon as it is read by the slave, and will not be passed to the master as active configuration.
Bitten is a Python-based framework for collecting various software metrics via continuous integration. It builds on Trac to provide an integrated web-based user interface.
Bitten is written in Python, so make sure that you have Python installed. You'll need Python 2.4 or later for running build slave. The build master is a plugin for Trac 0.11, and should still work with Python 2.3. Also, make sure that setuptools, version 0.6a2 or later, is installed.
If that's taken care of, you just need to download and unpack the Bitten distribution, and execute the command:
$ python setup.py install
from the top of the directory where you unpacked (or checked out) the Bitten code. Note that you may need administrator/root privileges for this step, as it will by default attempt to install Bitten to the Python site-packages directory on your system.
It's also a good idea to run the unit tests at this point, to make sure that the code works as expected on your platform (please note that Trac needs to be installed for the tests to run; see below):
$ python setup.py test
It is also possible to install only the build slave, installing only the parts of Bitten that are needed by clients to run builds:
$ python setup.py --without-master install
What's left to do now depends on whether you want to use the build master and web interface, or just the build slave. In the latter case, you're already done. You might need to install software that the build of your project requires, but the Bitten build slave itself doesn't require anything extra.
For the build master and web interface, you'll need to install Trac 0.11 or later. Please refer to the Trac documentation for information on how it is installed.
Once both Bitten and Trac are installed and working, you'll have to introduce Bitten to your Trac project environment. If you don't have a Trac project set up yet, you'll need to do so in order to use Bitten.
If you already have a Trac project environment, the Bitten plugin needs to be explicitly enabled in the Trac configuration. This is done by adding it to the [components] section in /path/to/projenv/conf/trac.ini:
[components]
bitten.* = enabled
The Trac web interface should now inform you with an error message that the environment needs to be upgraded. To do this, run:
$ trac-admin /path/to/projenv upgrade
This will create the database tables and directories that Bitten requires. You probably also want to grant permissions to someone (such as yourself) to manage build configurations, and allow anonymous users to view the status and results of builds:
$ trac-admin /path/to/projenv permission add [yourname] BUILD_ADMIN $ trac-admin /path/to/projenv permission add anonymous BUILD_VIEW
Build slaves (see next section) will need permission to download build configurations and submit results. You can grant the permission using:
$ trac-admin /path/to/projenv permission add [slavegroup] BUILD_EXEC
Alternatively you may allow anyone to submit builds by giving anonymous users this permission.
You should now see an additional tab labeled "Build Status" in the Trac navigation bar. This link will take you to the list of build configurations, which at this point is of course empty.
If Bitten is installed, and you are logged in as a user with the required permissions, you should see additional administration pages inside the “Admin” area, under a group named “Builds”. These pages allow you to set options of the build master, and manage build configurations.
Add a new build configuration and fill out the form. Also, add at least one target platform after saving the configuration. Last but not least, you'll have to "activate" your new build configuration.
The build slave can be run on any machine that can connect to the machine on which the build master is running. The installation of Bitten should have put a bitten-slave executable on your path. If the script is not on your path, look for it in the bin or scripts subdirectory of your Python installation.
To get a list of options for the build slave, execute it with the --help option:
$ bitten-slave --help
To run the build slave against a Bitten-enabled Trac site installed at http://myproject.example.org/trac, you'd run:
$ bitten-slave http://myproject.example.org/trac/builds
Bitten supports the ability to link between any wiki-enabled objects in Trac.
To link to a particular build, use the TracLink syntax build:N (where N is the number of the build).
Linking to a particular step of the build is also supported by adding an anchor reference, like build:N#Test. If the step ID contains spaces, the link must be quoted: build:"N#My Step".