<html lang="en"> <head> <title>Builder Configuration - BuildBot Manual - 0.8.4p1</title> <meta http-equiv="Content-Type" content="text/html"> <meta name="description" content="BuildBot Manual - 0.8.4p1"> <meta name="generator" content="makeinfo 4.13"> <link title="Top" rel="start" href="index.html#Top"> <link rel="up" href="Builders.html#Builders" title="Builders"> <link rel="next" href="Merging-Build-Requests.html#Merging-Build-Requests" title="Merging Build Requests"> <link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage"> <!-- This is the BuildBot manual for Buildbot version 0.8.4p1. Copyright (C) 2005, 2006, 2009, 2010 Brian Warner Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved.--> <meta http-equiv="Content-Style-Type" content="text/css"> <style type="text/css"><!-- pre.display { font-family:inherit } pre.format { font-family:inherit } pre.smalldisplay { font-family:inherit; font-size:smaller } pre.smallformat { font-family:inherit; font-size:smaller } pre.smallexample { font-size:smaller } pre.smalllisp { font-size:smaller } span.sc { font-variant:small-caps } span.roman { font-family:serif; font-weight:normal; } span.sansserif { font-family:sans-serif; font-weight:normal; } --></style> </head> <body> <div class="node"> <a name="Builder-Configuration"></a> <p> Next: <a rel="next" accesskey="n" href="Merging-Build-Requests.html#Merging-Build-Requests">Merging Build Requests</a>, Up: <a rel="up" accesskey="u" href="Builders.html#Builders">Builders</a> <hr> </div> <h4 class="subsection">4.10.1 Builder Configuration</h4> <p><a name="index-c_005b_0027builders_0027_005d-69"></a> The <code>c['builders']</code> key is a list of objects giving configuration for the Builders. For more information, See <a href="Builder.html#Builder">Builder</a>. The class definition for the builder configuration is in <code>buildbot.config</code>. In the configuration file, its use looks like: <pre class="example"> from buildbot.config import BuilderConfig c['builders'] = [ BuilderConfig(name='quick', slavenames=['bot1', 'bot2'], factory=f_quick), BuilderConfig(name='thorough', slavename='bot1', factory=f_thorough), ] </pre> <p>The constructor takes the following keyword arguments: <dl> <dt><code>name</code><dd>This specifies the Builder's name, which is used in status reports. <br><dt><code>slavename</code><br><dt><code>slavenames</code><dd>These arguments specify the buildslave or buildslaves that will be used by this Builder. All slaves names must appear in the <code>c['slaves']</code> list. Each buildslave can accomodate multiple Builders. The <code>slavenames</code> parameter can be a list of names, while <code>slavename</code> can specify only one slave. <br><dt><code>factory</code><dd>This is a <code>buildbot.process.factory.BuildFactory</code> instance which controls how the build is performed. Full details appear in their own section, See <a href="Build-Factories.html#Build-Factories">Build Factories</a>. Parameters like the location of the CVS repository and the compile-time options used for the build are generally provided as arguments to the factory's constructor. </dl> <p>Other optional keys may be set on each Builder: <dl> <dt><code>builddir</code><dd>Specifies the name of a subdirectory (under the base directory) in which everything related to this builder will be placed on the buildmaster. This holds build status information. If not set, defaults to <code>name</code> with some characters escaped. Each builder must have a unique build directory. <br><dt><code>slavebuilddir</code><dd>Specifies the name of a subdirectory (under the base directory) in which everything related to this builder will be placed on the buildslave. This is where checkouts, compiles, and tests are run. If not set, defaults to <code>builddir</code>. If a slave is connected to multiple builders that share the same <code>slavebuilddir</code>, make sure the slave is set to run one build at a time or ensure this is fine to run multiple builds from the same directory simultaneously. <br><dt><code>category</code><dd>If provided, this is a string that identifies a category for the builder to be a part of. Status clients can limit themselves to a subset of the available categories. A common use for this is to add new builders to your setup (for a new module, or for a new buildslave) that do not work correctly yet and allow you to integrate them with the active builders. You can put these new builders in a test category, make your main status clients ignore them, and have only private status clients pick them up. As soon as they work, you can move them over to the active category. <br><dt><code>nextSlave</code><dd>If provided, this is a function that controls which slave will be assigned future jobs. The function is passed two arguments, the <code>Builder</code> object which is assigning a new job, and a list of <code>SlaveBuilder</code> objects. The function should return one of the <code>SlaveBuilder</code> objects, or <code>None</code> if none of the available slaves should be used. This function can optionally return a Deferred which should fire with the same results. <br><dt><code>nextBuild</code><dd>If provided, this is a function that controls which build request will be handled next. The function is passed two arguments, the <code>Builder</code> object which is assigning a new job, and a list of <code>BuildRequest</code> objects representing pending build requests, sorted by increasing submission time. . The function should return one of the <code>BuildRequest</code> objects, or <code>None</code> if none of the pending builds should be started. This function can optionally return a Deferred which should fire with the same results. <br><dt><code>locks</code><dd>This argument specifies a list of locks that apply to this builder; See <a href="Interlocks.html#Interlocks">Interlocks</a>. <br><dt><code>env</code><dd>A Builder may be given a dictionary of environment variables in this parameter. The variables are used in see <a href="ShellCommand.html#ShellCommand">ShellCommand</a> steps in builds created by this builder. The environment variables will override anything in the buildslave's environment. Variables passed directly to a <code>ShellCommand</code> will override variables of the same name passed to the Builder. <p>For example, if you have a pool of identical slaves, it is often easier to manage variables like PATH from Buildbot, rather than manually editing it inside of the slaves' environment. <pre class="example"> f = factory.BuildFactory f.addStep(ShellCommand( command=['bash', './configure'])) f.addStep(Compile()) c['builders'] = [ BuilderConfig(name='test', factory=f, slavenames=['slave1', 'slave2', 'slave3', 'slave4'], env={'PATH': '/opt/local/bin:/opt/app/bin:/usr/local/bin:/usr/bin'}), ] </pre> <br><dt><code>mergeRequests</code><dd>Specifies how build requests for this builder should be merged, overriding the global option (see <a href="Merging-Build-Requests-_0028global-option_0029.html#Merging-Build-Requests-_0028global-option_0029">Merging Build Requests (global option)</a>). See <a href="Merging-Build-Requests.html#Merging-Build-Requests">Merging Build Requests</a> for details. <br><dt><code>properties</code><dd>A builder may be given a dictionary of <a href="Build-Properties.html#Build-Properties">Build Properties</a> specific for this builder in this parameter. Those values can be used later on like other properties. see <a href="WithProperties.html#WithProperties">WithProperties</a>. </dl> </body></html>