<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Global Configuration — Buildbot 0.8.5 documentation</title>
<link rel="stylesheet" href="../_static/agogo.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '0.8.5',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<link rel="shortcut icon" href="../_static/buildbot.ico"/>
<link rel="top" title="Buildbot 0.8.5 documentation" href="../index.html" />
<link rel="up" title="Configuration" href="configuration.html" />
<link rel="next" title="Change Sources" href="cfg-changesources.html" />
<link rel="prev" title="Configuring Buildbot" href="cfg-intro.html" />
</head>
<body>
<div class="header-wrapper">
<div class="header">
<p class="logo"><a href="../index.html">
<img class="logo" src="../_static/header-text-transparent.png" alt="Logo"/>
</a></p>
<div class="headertitle"><a
href="../index.html">Buildbot 0.8.5 documentation</a></div>
<div class="rel">
<a href="cfg-intro.html" title="Configuring Buildbot"
accesskey="P">previous</a> |
<a href="cfg-changesources.html" title="Change Sources"
accesskey="N">next</a> |
<a href="../py-modindex.html" title="Python Module Index"
>modules</a> |
<a href="../genindex.html" title="General Index"
accesskey="I">index</a>
</div>
</div>
</div>
<div class="content-wrapper">
<div class="content">
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="global-configuration">
<h1>Global Configuration<a class="headerlink" href="#global-configuration" title="Permalink to this headline">¶</a></h1>
<p>The keys in this section affect the operations of the buildmaster globally.</p>
<div class="section" id="database-specification">
<span id="cfg-db_url"></span><span id="id1"></span><h2>Database Specification<a class="headerlink" href="#database-specification" title="Permalink to this headline">¶</a></h2>
<p>Buildbot requires a connection to a database to maintain certain state
information, such as tracking pending build requests. By default this is
stored in a sqlite file called <tt class="file docutils literal"><span class="pre">state.sqlite</span></tt> in the base directory of your
master. This can be overridden with the <tt class="docutils literal"><span class="pre">db_url</span></tt> parameter.</p>
<p>The format of this parameter is completely documented at
<a class="reference external" href="http://www.sqlalchemy.org/docs/dialects/">http://www.sqlalchemy.org/docs/dialects/</a>, but is generally of the form
<tt class="docutils literal"><span class="pre">driver://[username:password@]host:port/database[?args]</span></tt>.</p>
<p>Notes for particular database backends:</p>
<div class="section" id="sqlite">
<span id="index-0"></span><h3>SQLite<a class="headerlink" href="#sqlite" title="Permalink to this headline">¶</a></h3>
<p>For sqlite databases, since there is no host and port, relative paths are
specified with <tt class="docutils literal"><span class="pre">sqlite:///</span></tt> and absolute paths with <tt class="docutils literal"><span class="pre">sqlite:////</span></tt>.
Examples:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'db_url'</span><span class="p">]</span> <span class="o">=</span> <span class="s">"sqlite:///state.sqlite"</span>
</pre></div>
</div>
<p>No special configuration is required to use SQLite.</p>
<p>If you have trouble with "database is locked" exceptions, try adding
<tt class="docutils literal"><span class="pre">serialize_access=1</span></tt> to the DB URL as a workaround:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'db_url'</span><span class="p">]</span> <span class="o">=</span> <span class="s">"sqlite:///state.sqlite?serialize_access=1"</span>
</pre></div>
</div>
<p>and please file a bug at <a class="reference external" href="http://trac.buildbot.net">http://trac.buildbot.net</a>.</p>
</div>
<div class="section" id="mysql">
<span id="index-1"></span><h3>MySQL<a class="headerlink" href="#mysql" title="Permalink to this headline">¶</a></h3>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'db_url'</span><span class="p">]</span> <span class="o">=</span> <span class="s">"mysql://user:pass@somehost.com/database_name?max_idle=300"</span>
</pre></div>
</div>
<p>The <tt class="docutils literal"><span class="pre">max_idle</span></tt> argument for MySQL connections is unique to Buildbot, and
should be set to something less than the <tt class="docutils literal"><span class="pre">wait_timeout</span></tt> configured for your
server. This controls the SQLAlchemy <tt class="docutils literal"><span class="pre">pool_recycle</span></tt> parameter, which
defaults to no timeout. Setting this parameter ensures that connections are
closed and re-opened after the configured amount of idle time. If you see
errors such as <tt class="docutils literal"><span class="pre">_mysql_exceptions.OperationalError:</span> <span class="pre">(2006,</span> <span class="pre">'MySQL</span> <span class="pre">server</span>
<span class="pre">has</span> <span class="pre">gone</span> <span class="pre">away')</span></tt>, this means your <tt class="docutils literal"><span class="pre">max_idle</span></tt> setting is probably too high.
<tt class="docutils literal"><span class="pre">show</span> <span class="pre">global</span> <span class="pre">variables</span> <span class="pre">like</span> <span class="pre">'wait_timeout';</span></tt> will show what the currently
configured <tt class="docutils literal"><span class="pre">wait_timeout</span></tt> is on your MySQL server.</p>
<p>Buildbot requires <tt class="docutils literal"><span class="pre">use_unique=True</span></tt> and <tt class="docutils literal"><span class="pre">charset=utf8</span></tt>, and will add
them automatically, so they do not need to be specified in <tt class="docutils literal"><span class="pre">db_url</span></tt>.</p>
<p>MySQL defaults to the MyISAM storage engine, but this can be overridden with
the <tt class="docutils literal"><span class="pre">storage_engine</span></tt> URL argument. Note that, because of InnoDB's
extremely short key length limitations, it cannot be used to run Buildbot. See
<a class="reference external" href="http://bugs.mysql.com/bug.php?id=4541">http://bugs.mysql.com/bug.php?id=4541</a> for more information.</p>
<p>Buildbot uses temporary tables internally to manage large transactions. MySQL
has trouble doing replication with temporary tables, so if you are using a
replicated MySQL installation, you may need to handle this situation carefully.
The MySQL documentation
(<a class="reference external" href="http://dev.mysql.com/doc/refman/5.5/en/replication-features-temptables.html">http://dev.mysql.com/doc/refman/5.5/en/replication-features-temptables.html</a>)
recommends using <tt class="docutils literal"><span class="pre">--replicate-wild-ignore-table</span></tt> to ignore temporary
tables that should not be replicated. All Buildbot temporary tables begin with
<tt class="docutils literal"><span class="pre">bbtmp_</span></tt>, so an option such as
<tt class="docutils literal"><span class="pre">--replicate-wild-ignore-table=bbtmp_.*</span></tt> may help.</p>
</div>
<div class="section" id="postgres">
<span id="index-2"></span><h3>Postgres<a class="headerlink" href="#postgres" title="Permalink to this headline">¶</a></h3>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'db_url'</span><span class="p">]</span> <span class="o">=</span> <span class="s">"postgresql://username@@hostname/dbname"</span>
</pre></div>
</div>
<p>No special configuration is required to use Postgres.</p>
<span class="target" id="cfg-multiMaster"></span></div>
</div>
<div class="section" id="multi-master-mode">
<span id="cfg-db_poll_interval"></span><span id="id2"></span><h2>Multi-master mode<a class="headerlink" href="#multi-master-mode" title="Permalink to this headline">¶</a></h2>
<p>Normally buildbot operates using a single master process that uses the
configured database to save state.</p>
<p>It is possible to configure buildbot to have multiple master processes that
share state in the same database. This has been well tested using a MySQL
database. There are several benefits of Multi-master mode:</p>
<blockquote>
<div><ul class="simple">
<li>You can have large numbers of build slaves handling the same queue of build
requests.A single master can only handle so many slaves (the
number is based on a number of factors including type of builds,
number of builds, and master and slave IO and CPU capacity - there
is no fixed formula). By adding another master which shares the
queue of build requests, you can attach more slaves to this
additional master, and increase your build throughput.</li>
<li>You can shut one master down to do maintenance, and other masters will continue
to do builds.</li>
</ul>
</div></blockquote>
<p>State that is shared in the database includes:</p>
<blockquote>
<div><ul class="simple">
<li>List of changes</li>
<li>Scheduler names and internal state</li>
<li>Build requests, including the builder name</li>
</ul>
</div></blockquote>
<p>Because of this shared state, you are strongly encouraged to:</p>
<blockquote>
<div><ul class="simple">
<li>Ensure that each named scheduler runs on only one master. If the
same scheduler runs on multiple masters, it will trigger duplicate
builds and may produce other undesirable behaviors.</li>
<li>Ensure builder names are unique for a given build factory implementation. You
can have the same builder name configured on many masters, but if the build
factories differ, you will get different results depending on which master
claims the build.</li>
</ul>
</div></blockquote>
<p>One suggested configuration is to have one buildbot master configured with just
the scheduler and change sources; and then other masters configured with just
the builders.</p>
<p>To enable multi-master mode in this configuration, you will need to set the
<tt class="docutils literal"><span class="pre">multiMaster</span></tt> option so that buildbot doesn't warn about missing schedulers or
builders. You will also need to set <tt class="docutils literal"><span class="pre">db_poll_interval</span></tt> to the masters with only
builders check the database for new build requests at the configured interval.</p>
<div class="highlight-python"><div class="highlight"><pre><span class="c"># Enable multiMaster mode; disables warnings about unknown builders and</span>
<span class="c"># schedulers</span>
<span class="n">c</span><span class="p">[</span><span class="s">'multiMaster'</span><span class="p">]</span> <span class="o">=</span> <span class="bp">True</span>
<span class="c"># Check for new build requests every 60 seconds</span>
<span class="n">c</span><span class="p">[</span><span class="s">'db_poll_interval'</span><span class="p">]</span> <span class="o">=</span> <span class="mi">60</span>
</pre></div>
</div>
<span class="target" id="cfg-buildbotURL"></span><span class="target" id="cfg-titleURL"></span></div>
<div class="section" id="site-definitions">
<span id="cfg-title"></span><h2>Site Definitions<a class="headerlink" href="#site-definitions" title="Permalink to this headline">¶</a></h2>
<p>Three basic settings describe the buildmaster in status reports:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'title'</span><span class="p">]</span> <span class="o">=</span> <span class="s">"Buildbot"</span>
<span class="n">c</span><span class="p">[</span><span class="s">'titleURL'</span><span class="p">]</span> <span class="o">=</span> <span class="s">"http://buildbot.sourceforge.net/"</span>
<span class="n">c</span><span class="p">[</span><span class="s">'buildbotURL'</span><span class="p">]</span> <span class="o">=</span> <span class="s">"http://localhost:8010/"</span>
</pre></div>
</div>
<p><a class="reference internal" href="#cfg-title" title="title"><tt class="xref bb bb-cfg docutils literal"><span class="pre">title</span></tt></a> is a short string that will appear at the top of this
buildbot installation's <tt class="xref py py-class docutils literal"><span class="pre">html.WebStatus</span></tt> home page (linked to the
<a class="reference internal" href="#cfg-titleURL" title="titleURL"><tt class="xref bb bb-cfg docutils literal"><span class="pre">titleURL</span></tt></a>), and is embedded in the title of the waterfall HTML
page.</p>
<p><a class="reference internal" href="#cfg-titleURL" title="titleURL"><tt class="xref bb bb-cfg docutils literal"><span class="pre">titleURL</span></tt></a> is a URL string that must end with a slash (<tt class="docutils literal"><span class="pre">/</span></tt>).
HTML status displays will show <tt class="docutils literal"><span class="pre">title</span></tt> as a link to
<a class="reference internal" href="#cfg-titleURL" title="titleURL"><tt class="xref bb bb-cfg docutils literal"><span class="pre">titleURL</span></tt></a>. This URL is often used to provide a link from
buildbot HTML pages to your project's home page.</p>
<p>The <a class="reference internal" href="#cfg-buildbotURL" title="buildbotURL"><tt class="xref bb bb-cfg docutils literal"><span class="pre">buildbotURL</span></tt></a> string should point to the location where the buildbot's
internal web server is visible. This URL must end with a slash (<tt class="docutils literal"><span class="pre">/</span></tt>).
This typically uses the port number set for the web status (<a class="reference internal" href="cfg-statustargets.html#status-WebStatus" title="WebStatus"><tt class="xref bb bb-status docutils literal"><span class="pre">WebStatus</span></tt></a>):
the buildbot needs your help to figure out a suitable externally-visible host
URL.</p>
<p>When status notices are sent to users (either by email or over IRC),
<a class="reference internal" href="#cfg-buildbotURL" title="buildbotURL"><tt class="xref bb bb-cfg docutils literal"><span class="pre">buildbotURL</span></tt></a> will be used to create a URL to the specific build
or problem that they are being notified about. It will also be made
available to queriers (over IRC) who want to find out where to get
more information about this buildbot.</p>
<span class="target" id="cfg-logCompressionLimit"></span><span class="target" id="cfg-logCompressionMethod"></span><span class="target" id="cfg-logMaxSize"></span></div>
<div class="section" id="log-handling">
<span id="cfg-logMaxTailSize"></span><h2>Log Handling<a class="headerlink" href="#log-handling" title="Permalink to this headline">¶</a></h2>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'logCompressionLimit'</span><span class="p">]</span> <span class="o">=</span> <span class="mi">16384</span>
<span class="n">c</span><span class="p">[</span><span class="s">'logCompressionMethod'</span><span class="p">]</span> <span class="o">=</span> <span class="s">'gz'</span>
<span class="n">c</span><span class="p">[</span><span class="s">'logMaxSize'</span><span class="p">]</span> <span class="o">=</span> <span class="mi">1024</span><span class="o">*</span><span class="mi">1024</span> <span class="c"># 1M</span>
<span class="n">c</span><span class="p">[</span><span class="s">'logMaxTailSize'</span><span class="p">]</span> <span class="o">=</span> <span class="mi">32768</span>
</pre></div>
</div>
<p>The <a class="reference internal" href="#cfg-logCompressionLimit" title="logCompressionLimit"><tt class="xref bb bb-cfg docutils literal"><span class="pre">logCompressionLimit</span></tt></a> enables compression of build logs on
disk for logs that are bigger than the given size, or disables that
completely if set to <tt class="docutils literal"><span class="pre">False</span></tt>. The default value is 4096, which should
be a reasonable default on most file systems. This setting has no impact
on status plugins, and merely affects the required disk space on the
master for build logs.</p>
<p>The <a class="reference internal" href="#cfg-logCompressionMethod" title="logCompressionMethod"><tt class="xref bb bb-cfg docutils literal"><span class="pre">logCompressionMethod</span></tt></a> controls what type of compression is used for
build logs. The default is 'bz2', and the other valid option is 'gz'. 'bz2'
offers better compression at the expense of more CPU time.</p>
<p>The <a class="reference internal" href="#cfg-logMaxSize" title="logMaxSize"><tt class="xref bb bb-cfg docutils literal"><span class="pre">logMaxSize</span></tt></a> parameter sets an upper limit (in bytes) to how large
logs from an individual build step can be. The default value is None, meaning
no upper limit to the log size. Any output exceeding <a class="reference internal" href="#cfg-logMaxSize" title="logMaxSize"><tt class="xref bb bb-cfg docutils literal"><span class="pre">logMaxSize</span></tt></a> will be
truncated, and a message to this effect will be added to the log's HEADER
channel.</p>
<p>If <a class="reference internal" href="#cfg-logMaxSize" title="logMaxSize"><tt class="xref bb bb-cfg docutils literal"><span class="pre">logMaxSize</span></tt></a> is set, and the output from a step exceeds the maximum,
the <a class="reference internal" href="#cfg-logMaxTailSize" title="logMaxTailSize"><tt class="xref bb bb-cfg docutils literal"><span class="pre">logMaxTailSize</span></tt></a> parameter controls how much of the end of the build
log will be kept. The effect of setting this parameter is that the log will
contain the first <a class="reference internal" href="#cfg-logMaxSize" title="logMaxSize"><tt class="xref bb bb-cfg docutils literal"><span class="pre">logMaxSize</span></tt></a> bytes and the last <a class="reference internal" href="#cfg-logMaxTailSize" title="logMaxTailSize"><tt class="xref bb bb-cfg docutils literal"><span class="pre">logMaxTailSize</span></tt></a>
bytes of output. Don't set this value too high, as the the tail of the log is
kept in memory.</p>
</div>
<div class="section" id="data-lifetime">
<h2>Data Lifetime<a class="headerlink" href="#data-lifetime" title="Permalink to this headline">¶</a></h2>
<span class="target" id="cfg-changeHorizon"></span><span class="target" id="cfg-buildHorizon"></span><span class="target" id="cfg-eventHorizon"></span><div class="section" id="horizons">
<span id="cfg-logHorizon"></span><h3>Horizons<a class="headerlink" href="#horizons" title="Permalink to this headline">¶</a></h3>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'changeHorizon'</span><span class="p">]</span> <span class="o">=</span> <span class="mi">200</span>
<span class="n">c</span><span class="p">[</span><span class="s">'buildHorizon'</span><span class="p">]</span> <span class="o">=</span> <span class="mi">100</span>
<span class="n">c</span><span class="p">[</span><span class="s">'eventHorizon'</span><span class="p">]</span> <span class="o">=</span> <span class="mi">50</span>
<span class="n">c</span><span class="p">[</span><span class="s">'logHorizon'</span><span class="p">]</span> <span class="o">=</span> <span class="mi">40</span>
<span class="n">c</span><span class="p">[</span><span class="s">'buildCacheSize'</span><span class="p">]</span> <span class="o">=</span> <span class="mi">15</span>
</pre></div>
</div>
<p>Buildbot stores historical information on disk in the form of "Pickle" files
and compressed logfiles. In a large installation, these can quickly consume
disk space, yet in many cases developers never consult this historical
information.</p>
<p>The <a class="reference internal" href="#cfg-changeHorizon" title="changeHorizon"><tt class="xref bb bb-cfg docutils literal"><span class="pre">changeHorizon</span></tt></a> key determines how many changes the master will
keep a record of. One place these changes are displayed is on the waterfall
page. This parameter defaults to 0, which means keep all changes indefinitely.</p>
<p>The <a class="reference internal" href="#cfg-buildHorizon" title="buildHorizon"><tt class="xref bb bb-cfg docutils literal"><span class="pre">buildHorizon</span></tt></a> specifies the minimum number of builds for each builder
which should be kept on disk. The <a class="reference internal" href="#cfg-eventHorizon" title="eventHorizon"><tt class="xref bb bb-cfg docutils literal"><span class="pre">eventHorizon</span></tt></a> specifies the minumum
number of events to keep -- events mostly describe connections and
disconnections of slaves, and are seldom helpful to developers. The
<a class="reference internal" href="#cfg-logHorizon" title="logHorizon"><tt class="xref bb bb-cfg docutils literal"><span class="pre">logHorizon</span></tt></a> gives the minimum number of builds for which logs should be
maintained; this parameter must be less than <a class="reference internal" href="#cfg-buildHorizon" title="buildHorizon"><tt class="xref bb bb-cfg docutils literal"><span class="pre">buildHorizon</span></tt></a>. Builds older
than <a class="reference internal" href="#cfg-logHorizon" title="logHorizon"><tt class="xref bb bb-cfg docutils literal"><span class="pre">logHorizon</span></tt></a> but not older than <a class="reference internal" href="#cfg-buildHorizon" title="buildHorizon"><tt class="xref bb bb-cfg docutils literal"><span class="pre">buildHorizon</span></tt></a> will maintain
their overall status and the status of each step, but the logfiles will be
deleted.</p>
<span class="target" id="cfg-caches"></span></div>
<div class="section" id="caches">
<span id="cfg-changeCacheSize"></span><h3>Caches<a class="headerlink" href="#caches" title="Permalink to this headline">¶</a></h3>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'caches'</span><span class="p">]</span> <span class="o">=</span> <span class="p">{</span>
<span class="s">'Changes'</span> <span class="p">:</span> <span class="mi">100</span><span class="p">,</span> <span class="c"># a.k.a. c['changeCacheSize']</span>
<span class="s">'chdicts'</span> <span class="p">:</span> <span class="mi">100</span><span class="p">,</span>
<span class="s">'BuildRequests'</span> <span class="p">:</span> <span class="mi">10</span><span class="p">,</span>
<span class="s">'SourceStamps'</span> <span class="p">:</span> <span class="mi">20</span><span class="p">,</span>
<span class="s">'ssdicts'</span> <span class="p">:</span> <span class="mi">20</span><span class="p">,</span>
<span class="s">'objectids'</span> <span class="p">:</span> <span class="mi">10</span><span class="p">,</span>
<span class="s">'usdicts'</span> <span class="p">:</span> <span class="mi">100</span><span class="p">,</span>
<span class="p">}</span>
<span class="n">c</span><span class="p">[</span><span class="s">'buildCacheSize'</span><span class="p">]</span> <span class="o">=</span> <span class="mi">500</span>
</pre></div>
</div>
<p>The <a class="reference internal" href="#cfg-caches" title="caches"><tt class="xref bb bb-cfg docutils literal"><span class="pre">caches</span></tt></a> configuration key contains the configuration for Buildbot's
in-memory caches. These caches keep frequently-used objects in memory to avoid
unnecessary trips to the database or to pickle files. Caches are divided by
object type, and each has a configurable maximum size. The default size for
each cache is 1, which allows Buildbot to make a number of optimizations
without consuming much memory. Larger, busier installations will likely want
to increase these values.</p>
<p>The available caches are:</p>
<dl class="docutils">
<dt><tt class="docutils literal"><span class="pre">Changes</span></tt></dt>
<dd><p class="first">the number of change objects to cache in memory. This should be larger than
the number of changes that typically arrive in the span of a few minutes,
otherwise your schedulers will be reloading changes from the database every
time they run. For distributed version control systems, like git or hg,
several thousand changes may arrive at once, so setting this parameter to
something like 10000 isn't unreasonable.</p>
<p class="last">This parameter is the same as the deprecated global parameter
<a class="reference internal" href="#cfg-changeCacheSize" title="changeCacheSize"><tt class="xref bb bb-cfg docutils literal"><span class="pre">changeCacheSize</span></tt></a>.</p>
</dd>
<dt><tt class="docutils literal"><span class="pre">chdicts</span></tt></dt>
<dd>The number of rows from the <tt class="docutils literal"><span class="pre">changes</span></tt> table to cache in memory. This
value should be similar to the value for <tt class="docutils literal"><span class="pre">Changes</span></tt>.</dd>
<dt><tt class="docutils literal"><span class="pre">BuildRequests</span></tt></dt>
<dd>the number of BuildRequest objects kept in memory. This number should be
higher than the typical number of outstanding build requests. If the master
ordinarily finds jobs for BuildRequests immediately, it can be set to a
relatively low value.</dd>
<dt><tt class="docutils literal"><span class="pre">SourceStamps</span></tt></dt>
<dd>the number of SourceStamp objects kept in memory. This number
should generally be similar to the number <tt class="docutils literal"><span class="pre">BuildRequesets</span></tt>.</dd>
<dt><tt class="docutils literal"><span class="pre">ssdicts</span></tt></dt>
<dd>The number of rows from the <tt class="docutils literal"><span class="pre">sourcestamps</span></tt> table to cache in memory. This
value should be similar to the value for <tt class="docutils literal"><span class="pre">SourceStamps</span></tt>.</dd>
<dt><tt class="docutils literal"><span class="pre">objectids</span></tt></dt>
<dd>The number of object IDs - a means to correlate an object in the
Buildbot configuration with an identity in the database - to
cache. In this version, object IDs are not looked up often during
runtime, so a relatively low value such as 10 is fine.</dd>
<dt><tt class="docutils literal"><span class="pre">usdicts</span></tt></dt>
<dd>The number of rows from the <tt class="docutils literal"><span class="pre">users</span></tt> table to cache in memory. Note that for
a given user there will be a row for each attribute that user has.</dd>
</dl>
<p id="cfg-buildCacheSize">The <a class="reference internal" href="#cfg-buildCacheSize" title="buildCacheSize"><tt class="xref bb bb-cfg docutils literal"><span class="pre">buildCacheSize</span></tt></a> parameter gives the number of builds
for each builder which are cached in memory. This number should be larger than
the number of builds required for commonly-used status displays (the waterfall
or grid views), so that those displays do not miss the cache on a
refresh.</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'buildCacheSize'</span><span class="p">]</span> <span class="o">=</span> <span class="mi">15</span>
</pre></div>
</div>
<span class="target" id="cfg-mergeRequests"></span></div>
</div>
<div class="section" id="merging-build-requests">
<span id="index-3"></span><h2>Merging Build Requests<a class="headerlink" href="#merging-build-requests" title="Permalink to this headline">¶</a></h2>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'mergeRequests'</span><span class="p">]</span> <span class="o">=</span> <span class="bp">False</span>
</pre></div>
</div>
<p>This is a global default value for builders' <a class="reference internal" href="#cfg-mergeRequests" title="mergeRequests"><tt class="xref bb bb-cfg docutils literal"><span class="pre">mergeRequests</span></tt></a> parameter,
and controls the merging of build requests. This parameter can be overridden
on a per-builder basis. See <a class="reference internal" href="cfg-builders.html#merging-build-requests"><em>Merging Build Requests</em></a> for the allowed
values for this parameter.</p>
<span class="target" id="index-4"></span></div>
<div class="section" id="prioritizing-builders">
<span id="cfg-prioritizeBuilders"></span><span id="id3"></span><h2>Prioritizing Builders<a class="headerlink" href="#prioritizing-builders" title="Permalink to this headline">¶</a></h2>
<div class="highlight-python"><pre>def prioritizeBuilders(buildmaster, builders):
# ...
c['prioritizeBuilders'] = prioritizeBuilders</pre>
</div>
<p>By default, buildbot will attempt to start builds on builders in order,
beginning with the builder with the oldest pending request. This behaviour can
be customized with the <a class="reference internal" href="#cfg-prioritizeBuilders" title="prioritizeBuilders"><tt class="xref bb bb-cfg docutils literal"><span class="pre">prioritizeBuilders</span></tt></a> configuration key, which
takes a callable. See <a class="reference internal" href="customization.html#builder-priority-functions"><em>Builder Priority Functions</em></a> for details on this
callable.</p>
<p>This parameter controls the order in which builders are permitted to start
builds, and is relevant in cases where there is resource contention between
builders, e.g., for a test database. It does not affect the order in which a
builder processes the build requests in its queue. For that purpose, see
<a class="reference internal" href="cfg-builders.html#prioritizing-builds"><em>Prioritizing Builds</em></a>.</p>
</div>
<div class="section" id="setting-the-pb-port-for-slaves">
<span id="cfg-slavePortnum"></span><span id="id4"></span><h2>Setting the PB Port for Slaves<a class="headerlink" href="#setting-the-pb-port-for-slaves" title="Permalink to this headline">¶</a></h2>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'slavePortnum'</span><span class="p">]</span> <span class="o">=</span> <span class="mi">10000</span>
</pre></div>
</div>
<p>The buildmaster will listen on a TCP port of your choosing for
connections from buildslaves. It can also use this port for
connections from remote Change Sources, status clients, and debug
tools. This port should be visible to the outside world, and you'll
need to tell your buildslave admins about your choice.</p>
<p>It does not matter which port you pick, as long it is externally
visible, however you should probably use something larger than 1024,
since most operating systems don't allow non-root processes to bind to
low-numbered ports. If your buildmaster is behind a firewall or a NAT
box of some sort, you may have to configure your firewall to permit
inbound connections to this port.</p>
<p><a class="reference internal" href="#cfg-slavePortnum" title="slavePortnum"><tt class="xref bb bb-cfg docutils literal"><span class="pre">slavePortnum</span></tt></a> is a <em>strports</em> specification string,
defined in the <tt class="docutils literal"><span class="pre">twisted.application.strports</span></tt> module (try
<tt class="docutils literal"><span class="pre">pydoc</span> <span class="pre">twisted.application.strports</span></tt> to get documentation on
the format). This means that you can have the buildmaster listen on a
localhost-only port by doing:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'slavePortnum'</span><span class="p">]</span> <span class="o">=</span> <span class="s">"tcp:10000:interface=127.0.0.1"</span>
</pre></div>
</div>
<p>This might be useful if you only run buildslaves on the same machine,
and they are all configured to contact the buildmaster at
<tt class="docutils literal"><span class="pre">localhost:10000</span></tt>.</p>
<span class="target" id="index-5"></span></div>
<div class="section" id="defining-global-properties">
<span id="cfg-properties"></span><h2>Defining Global Properties<a class="headerlink" href="#defining-global-properties" title="Permalink to this headline">¶</a></h2>
<p>The <a class="reference internal" href="#cfg-properties" title="properties"><tt class="xref bb bb-cfg docutils literal"><span class="pre">properties</span></tt></a> configuration key defines a dictionary
of properties that will be available to all builds started by the
buildmaster:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'properties'</span><span class="p">]</span> <span class="o">=</span> <span class="p">{</span>
<span class="s">'Widget-version'</span> <span class="p">:</span> <span class="s">'1.2'</span><span class="p">,</span>
<span class="s">'release-stage'</span> <span class="p">:</span> <span class="s">'alpha'</span>
<span class="p">}</span>
</pre></div>
</div>
</div>
<div class="section" id="debug-options">
<span id="cfg-debugPassword"></span><span id="id5"></span><h2>Debug Options<a class="headerlink" href="#debug-options" title="Permalink to this headline">¶</a></h2>
<p>If you set <a class="reference internal" href="#cfg-debugPassword" title="debugPassword"><tt class="xref bb bb-cfg docutils literal"><span class="pre">debugPassword</span></tt></a>, then you can connect to the
buildmaster with the diagnostic tool launched by <tt class="samp docutils literal"><span class="pre">buildbot</span>
<span class="pre">debugclient</span> <em><span class="pre">MASTER</span></em><span class="pre">:</span><em><span class="pre">PORT</span></em></tt>. From this tool, you can reload the config
file, manually force builds, and inject changes, which may be useful
for testing your buildmaster without actually commiting changes to
your repository (or before you have the Change Sources set up). The
debug tool uses the same port number as the slaves do:
<a class="reference internal" href="#cfg-slavePortnum" title="slavePortnum"><tt class="xref bb bb-cfg docutils literal"><span class="pre">slavePortnum</span></tt></a>, and is authenticated with this password.</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'debugPassword'</span><span class="p">]</span> <span class="o">=</span> <span class="s">"debugpassword"</span>
</pre></div>
</div>
<span class="target" id="index-6"></span></div>
<div class="section" id="manhole">
<span id="cfg-manhole"></span><h2>Manhole<a class="headerlink" href="#manhole" title="Permalink to this headline">¶</a></h2>
<p>If you set <a class="reference internal" href="#cfg-manhole" title="manhole"><tt class="xref bb bb-cfg docutils literal"><span class="pre">manhole</span></tt></a> to an instance of one of the classes in
<tt class="docutils literal"><span class="pre">buildbot.manhole</span></tt>, you can telnet or ssh into the buildmaster
and get an interactive Python shell, which may be useful for debugging
buildbot internals. It is probably only useful for buildbot
developers. It exposes full access to the buildmaster's account
(including the ability to modify and delete files), so it should not
be enabled with a weak or easily guessable password.</p>
<p>There are three separate <tt class="xref py py-class docutils literal"><span class="pre">Manhole</span></tt> classes. Two of them use SSH,
one uses unencrypted telnet. Two of them use a username+password
combination to grant access, one of them uses an SSH-style
<tt class="file docutils literal"><span class="pre">authorized_keys</span></tt> file which contains a list of ssh public keys.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Using any Manhole requires that <tt class="docutils literal"><span class="pre">pycrypto</span></tt> and
<tt class="docutils literal"><span class="pre">pyasn1</span></tt> be installed. These are not part of the normal Buildbot
dependencies.</p>
</div>
<dl class="docutils">
<dt><cite>manhole.AuthorizedKeysManhole</cite></dt>
<dd>You construct this with the name of a file that contains one SSH
public key per line, just like <tt class="file docutils literal"><span class="pre">~/.ssh/authorized_keys</span></tt>. If you
provide a non-absolute filename, it will be interpreted relative to
the buildmaster's base directory.</dd>
<dt><cite>manhole.PasswordManhole</cite></dt>
<dd>This one accepts SSH connections but asks for a username and password
when authenticating. It accepts only one such pair.</dd>
<dt><cite>manhole.TelnetManhole</cite></dt>
<dd>This accepts regular unencrypted telnet connections, and asks for a
username/password pair before providing access. Because this
username/password is transmitted in the clear, and because Manhole
access to the buildmaster is equivalent to granting full shell
privileges to both the buildmaster and all the buildslaves (and to all
accounts which then run code produced by the buildslaves), it is
highly recommended that you use one of the SSH manholes instead.</dd>
</dl>
<div class="highlight-python"><div class="highlight"><pre><span class="c"># some examples:</span>
<span class="kn">from</span> <span class="nn">buildbot</span> <span class="kn">import</span> <span class="n">manhole</span>
<span class="n">c</span><span class="p">[</span><span class="s">'manhole'</span><span class="p">]</span> <span class="o">=</span> <span class="n">manhole</span><span class="o">.</span><span class="n">AuthorizedKeysManhole</span><span class="p">(</span><span class="mi">1234</span><span class="p">,</span> <span class="s">"authorized_keys"</span><span class="p">)</span>
<span class="n">c</span><span class="p">[</span><span class="s">'manhole'</span><span class="p">]</span> <span class="o">=</span> <span class="n">manhole</span><span class="o">.</span><span class="n">PasswordManhole</span><span class="p">(</span><span class="mi">1234</span><span class="p">,</span> <span class="s">"alice"</span><span class="p">,</span> <span class="s">"mysecretpassword"</span><span class="p">)</span>
<span class="n">c</span><span class="p">[</span><span class="s">'manhole'</span><span class="p">]</span> <span class="o">=</span> <span class="n">manhole</span><span class="o">.</span><span class="n">TelnetManhole</span><span class="p">(</span><span class="mi">1234</span><span class="p">,</span> <span class="s">"bob"</span><span class="p">,</span> <span class="s">"snoop_my_password_please"</span><span class="p">)</span>
</pre></div>
</div>
<p>The <tt class="xref py py-class docutils literal"><span class="pre">Manhole</span></tt> instance can be configured to listen on a specific
port. You may wish to have this listening port bind to the loopback
interface (sometimes known as <cite>lo0</cite>, <cite>localhost</cite>, or 127.0.0.1) to
restrict access to clients which are running on the same host.</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">buildbot.manhole</span> <span class="kn">import</span> <span class="n">PasswordManhole</span>
<span class="n">c</span><span class="p">[</span><span class="s">'manhole'</span><span class="p">]</span> <span class="o">=</span> <span class="n">PasswordManhole</span><span class="p">(</span><span class="s">"tcp:9999:interface=127.0.0.1"</span><span class="p">,</span><span class="s">"admin"</span><span class="p">,</span><span class="s">"passwd"</span><span class="p">)</span>
</pre></div>
</div>
<p>To have the <tt class="xref py py-class docutils literal"><span class="pre">Manhole</span></tt> listen on all interfaces, use
<tt class="docutils literal"><span class="pre">"tcp:9999"</span></tt> or simply 9999. This port specification uses
<tt class="docutils literal"><span class="pre">twisted.application.strports</span></tt>, so you can make it listen on SSL
or even UNIX-domain sockets if you want.</p>
<p>Note that using any <tt class="xref py py-class docutils literal"><span class="pre">Manhole</span></tt> requires that the <a class="reference external" href="http://twistedmatrix.com/trac/wiki/TwistedConch">TwistedConch</a> package be
installed.</p>
<p>The buildmaster's SSH server will use a different host key than the
normal sshd running on a typical unix host. This will cause the ssh
client to complain about a <cite>host key mismatch</cite>, because it does not
realize there are two separate servers running on the same host. To
avoid this, use a clause like the following in your <tt class="file docutils literal"><span class="pre">.ssh/config</span></tt>
file:</p>
<div class="highlight-none"><div class="highlight"><pre>Host remotehost-buildbot
HostName remotehost
HostKeyAlias remotehost-buildbot
Port 9999
# use 'user' if you use PasswordManhole and your name is not 'admin'.
# if you use AuthorizedKeysManhole, this probably doesn't matter.
User admin
</pre></div>
</div>
<div class="section" id="using-manhole">
<h3>Using Manhole<a class="headerlink" href="#using-manhole" title="Permalink to this headline">¶</a></h3>
<p>After you have connected to a manhole instance, you will find yourself at a
Python prompt. You have access to two objects: <tt class="docutils literal"><span class="pre">master</span></tt> (the BuildMaster)
and <tt class="docutils literal"><span class="pre">status</span></tt> (the master's Status object). Most interesting objects on
the master can be reached from these two objects.</p>
<p>To aid in navigation, the <tt class="docutils literal"><span class="pre">show</span></tt> method is defined. It displays the
non-method attributes of an object.</p>
<p>A manhole session might look like:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="gp">>>> </span><span class="n">show</span><span class="p">(</span><span class="n">master</span><span class="p">)</span>
<span class="go">data attributes of <buildbot.master.BuildMaster instance at 0x7f7a4ab7df38></span>
<span class="go"> basedir : '/home/dustin/code/buildbot/t/buildbot/'...</span>
<span class="go"> botmaster : <type 'instance'></span>
<span class="go"> buildCacheSize : None</span>
<span class="go"> buildHorizon : None</span>
<span class="go"> buildbotURL : http://localhost:8010/</span>
<span class="go"> changeCacheSize : None</span>
<span class="go"> change_svc : <type 'instance'></span>
<span class="go"> configFileName : master.cfg</span>
<span class="go"> db : <class 'buildbot.db.connector.DBConnector'></span>
<span class="go"> db_poll_interval : None</span>
<span class="go"> db_url : sqlite:///state.sqlite</span>
<span class="go"> ...</span>
<span class="gp">>>> </span><span class="n">show</span><span class="p">(</span><span class="n">master</span><span class="o">.</span><span class="n">botmaster</span><span class="o">.</span><span class="n">builders</span><span class="p">[</span><span class="s">'win32'</span><span class="p">])</span>
<span class="go">data attributes of <Builder ''builder'' at 48963528></span>
<span class="go"> ...</span>
<span class="gp">>>> </span><span class="n">win32</span> <span class="o">=</span> <span class="n">_</span>
<span class="gp">>>> </span><span class="n">win32</span><span class="o">.</span><span class="n">category</span> <span class="o">=</span> <span class="s">'w32'</span>
</pre></div>
</div>
</div>
</div>
<div class="section" id="metrics-options">
<span id="cfg-metrics"></span><h2>Metrics Options<a class="headerlink" href="#metrics-options" title="Permalink to this headline">¶</a></h2>
<div class="highlight-python"><div class="highlight"><pre><span class="n">c</span><span class="p">[</span><span class="s">'metrics'</span><span class="p">]</span> <span class="o">=</span> <span class="nb">dict</span><span class="p">(</span><span class="n">log_interval</span><span class="o">=</span><span class="mi">10</span><span class="p">,</span> <span class="n">periodic_interval</span><span class="o">=</span><span class="mi">10</span><span class="p">)</span>
</pre></div>
</div>
<p><a class="reference internal" href="#cfg-metrics" title="metrics"><tt class="xref bb bb-cfg docutils literal"><span class="pre">metrics</span></tt></a> can be a dictionary that configures various aspects
of the metrics subsystem. If <a class="reference internal" href="#cfg-metrics" title="metrics"><tt class="xref bb bb-cfg docutils literal"><span class="pre">metrics</span></tt></a> is <tt class="docutils literal"><span class="pre">None</span></tt>, then metrics
collection, logging and reporting will be disabled.</p>
<p><tt class="docutils literal"><span class="pre">log_interval</span></tt> determines how often metrics should be logged to
twistd.log. It default to 60s. If set to 0 or <tt class="docutils literal"><span class="pre">None</span></tt>, then logging of
metrics will be disabled. This value can be changed via a reconfig.</p>
<p><tt class="docutils literal"><span class="pre">periodic_interval</span></tt> determines how often various non-event based
metrics are collected, such as memory usage, uncollectable garbage,
reactor delay. This defaults to 10s. If set to 0 or <tt class="docutils literal"><span class="pre">None</span></tt>, then
periodic collection of this data is disabled. This value can also be
changed via a reconfig.</p>
<p>Read more about metrics in the <a class="reference internal" href="../developer/metrics.html#metrics"><em>Metrics</em></a> section in the developer
documentation.</p>
</div>
<div class="section" id="users-options">
<span id="cfg-user_managers"></span><span id="id6"></span><h2>Users Options<a class="headerlink" href="#users-options" title="Permalink to this headline">¶</a></h2>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">buildbot.process.users</span> <span class="kn">import</span> <span class="n">manual</span>
<span class="n">c</span><span class="p">[</span><span class="s">'user_managers'</span><span class="p">]</span> <span class="o">=</span> <span class="p">[]</span>
<span class="n">c</span><span class="p">[</span><span class="s">'user_managers'</span><span class="p">]</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="n">manual</span><span class="o">.</span><span class="n">CommandlineUserManager</span><span class="p">(</span><span class="n">username</span><span class="o">=</span><span class="s">"user"</span><span class="p">,</span>
<span class="n">passwd</span><span class="o">=</span><span class="s">"userpw"</span><span class="p">,</span>
<span class="n">port</span><span class="o">=</span><span class="mi">9990</span><span class="p">))</span>
</pre></div>
</div>
<p><a class="reference internal" href="#cfg-user_managers" title="user_managers"><tt class="xref bb bb-cfg docutils literal"><span class="pre">user_managers</span></tt></a> contains a list of ways to manually manage User Objects
within Buildbot (see <a class="reference internal" href="concepts.html#user-objects"><em>User Objects</em></a>). Currently implemented is a
commandline tool <cite>buildbot user</cite>, described at length in <a class="reference internal" href="cmdline.html#cmdline-user" title="user"><tt class="xref bb bb-cmdline docutils literal"><span class="pre">user</span></tt></a>.
In the future, a web client will also be able to manage User Objects and
their attributes.</p>
<p>As shown above, to enable the <cite>buildbot user</cite> tool, you must initialize a
<cite>CommandlineUserManager</cite> instance in your <cite>master.cfg</cite>.
<cite>CommandlineUserManager</cite> instances require the following arguments:</p>
<dl class="docutils">
<dt><tt class="docutils literal"><span class="pre">username</span></tt></dt>
<dd>This is the <cite>username</cite> that will be registered on the PB connection
and need to be used when calling <cite>buildbot user</cite>.</dd>
<dt><tt class="docutils literal"><span class="pre">passwd</span></tt></dt>
<dd>This is the <cite>passwd</cite> that will be registered on the PB connection
and need to be used when calling <cite>buildbot user</cite>.</dd>
<dt><tt class="docutils literal"><span class="pre">port</span></tt></dt>
<dd>The PB connection <cite>port</cite> must be different than <cite>c['slavePortnum']</cite>
and be specified when calling <cite>buildbot user</cite></dd>
</dl>
</div>
<div class="section" id="input-validation">
<span id="cfg-validation"></span><span id="id7"></span><h2>Input Validation<a class="headerlink" href="#input-validation" title="Permalink to this headline">¶</a></h2>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">import</span> <span class="nn">re</span>
<span class="n">c</span><span class="p">[</span><span class="s">'validation'</span><span class="p">]</span> <span class="o">=</span> <span class="p">{</span>
<span class="s">'branch'</span> <span class="p">:</span> <span class="n">re</span><span class="o">.</span><span class="n">compile</span><span class="p">(</span><span class="s">r'^[\w.+/~-]*$'</span><span class="p">),</span>
<span class="s">'revision'</span> <span class="p">:</span> <span class="n">re</span><span class="o">.</span><span class="n">compile</span><span class="p">(</span><span class="s">r'^[ \w\.\-\/]*$'</span><span class="p">),</span>
<span class="s">'property_name'</span> <span class="p">:</span> <span class="n">re</span><span class="o">.</span><span class="n">compile</span><span class="p">(</span><span class="s">r'^[\w\.\-\/\~:]*$'</span><span class="p">),</span>
<span class="s">'property_value'</span> <span class="p">:</span> <span class="n">re</span><span class="o">.</span><span class="n">compile</span><span class="p">(</span><span class="s">r'^[\w\.\-\/\~:]*$'</span><span class="p">),</span>
<span class="p">}</span>
</pre></div>
</div>
<p>This option configures the validation applied to user inputs of various types.
This validation is important since these values are often included in
command-line arguments executed on slaves. Allowing arbitrary input from
untrusted users may raise security concerns.</p>
<p>The keys describe the type of input validated; the values are compiled regular
expressions against which the input will be matched. The defaults for each
type of input are those given in the example, above.</p>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="sidebar">
<h3>Table Of Contents</h3>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="../tutorial/index.html">Buildbot Tutorial</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="index.html">Buildbot Manual</a><ul class="current">
<li class="toctree-l2"><a class="reference internal" href="introduction.html">Introduction</a></li>
<li class="toctree-l2"><a class="reference internal" href="installation.html">Installation</a></li>
<li class="toctree-l2"><a class="reference internal" href="concepts.html">Concepts</a></li>
<li class="toctree-l2 current"><a class="reference internal" href="configuration.html">Configuration</a><ul class="current">
<li class="toctree-l3"><a class="reference internal" href="cfg-intro.html">Configuring Buildbot</a></li>
<li class="toctree-l3 current"><a class="current reference internal" href="">Global Configuration</a><ul class="simple">
</ul>
</li>
<li class="toctree-l3"><a class="reference internal" href="cfg-changesources.html">Change Sources</a></li>
<li class="toctree-l3"><a class="reference internal" href="cfg-schedulers.html">Schedulers</a></li>
<li class="toctree-l3"><a class="reference internal" href="cfg-buildslaves.html">Buildslaves</a></li>
<li class="toctree-l3"><a class="reference internal" href="cfg-builders.html">Builder Configuration</a></li>
<li class="toctree-l3"><a class="reference internal" href="cfg-buildfactories.html">Build Factories</a></li>
<li class="toctree-l3"><a class="reference internal" href="cfg-properties.html">Properties</a></li>
<li class="toctree-l3"><a class="reference internal" href="cfg-buildsteps.html">Build Steps</a></li>
<li class="toctree-l3"><a class="reference internal" href="cfg-interlocks.html">Interlocks</a></li>
<li class="toctree-l3"><a class="reference internal" href="cfg-statustargets.html">Status Targets</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="customization.html">Customization</a></li>
<li class="toctree-l2"><a class="reference internal" href="cmdline.html">Command-line Tool</a></li>
<li class="toctree-l2"><a class="reference internal" href="resources.html">Resources</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="../developer/index.html">Buildbot Development</a></li>
</ul>
<h3 style="margin-top: 1.5em;">Search</h3>
<form class="search" action="../search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<div class="clearer"></div>
</div>
</div>
<div class="footer-wrapper">
<div class="footer">
<div class="left">
<a href="cfg-intro.html" title="Configuring Buildbot"
>previous</a> |
<a href="cfg-changesources.html" title="Change Sources"
>next</a> |
<a href="../py-modindex.html" title="Python Module Index"
>modules</a> |
<a href="../genindex.html" title="General Index"
>index</a>
<br/>
<a href="../_sources/manual/cfg-global.txt"
rel="nofollow">Show Source</a>
</div>
<div class="right">
<div class="footer">
© Copyright Buildbot Team Members.
Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.
</div>
</div>
<div class="clearer"></div>
</div>
</div>
</body>
</html>
