The config file is, fundamentally, just a piece of Python code which
defines a dictionary named BuildmasterConfig, with a number of
keys that are treated specially. You don't need to know Python to do
basic configuration, though, you can just copy the syntax of the
sample file. If you are comfortable writing Python code,
however, you can use all the power of a full programming language to
achieve more complicated configurations.
The BuildmasterConfig name is the only one which matters: all
other names defined during the execution of the file are discarded.
When parsing the config file, the Buildmaster generally compares the
old configuration with the new one and performs the minimum set of
actions necessary to bring the buildbot up to date: Builders which are
not changed are left untouched, and Builders which are modified get to
keep their old event history.
The beginning of the master.cfg file typically starts with something like:
BuildmasterConfig = c = {}
Therefore a config key of change_source will usually appear in
master.cfg as c['change_source'].
See Configuration Index for a full list of BuildMasterConfig
keys.
Python comments start with a hash character (“#”), tuples are defined with
(parenthesis, pairs), and lists (arrays) are defined with [square,
brackets]. Tuples and listsk are mostly interchangeable. Dictionaries (data
structures which map “keys” to “values”) are defined with curly braces:
{'key1': 'value1', 'key2': 'value2'} . Function calls (and object
instantiation) can use named parameters, like w =
html.Waterfall(http_port=8010).
The config file starts with a series of import statements, which make
various kinds of Steps and Status targets available for later use. The main
BuildmasterConfig dictionary is created, then it is populated with a
variety of keys, described section-by-section in subsequent chapters.