c['changeHorizon'] = 200 c['buildHorizon'] = 100 c['eventHorizon'] = 50 c['logHorizon'] = 40 c['buildCacheSize'] = 15 c['changeCacheSize'] = 10000
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.
c['changeHorizon'] 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.
buildHorizon specifies the minimum number of builds for each builder
which should be kept on disk. The
eventHorizon specifies the minumum
number of events to keep – events mostly describe connections and
disconnections of slaves, and are seldom helpful to developers. The
logHorizon gives the minimum number of builds for which logs should be
maintained; this parameter must be less than
buildHorizon. Builds older
logHorizon but not older than
buildHorizon will maintain
their overall status and the status of each step, but the logfiles will be
buildCacheSize 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.
changeCacheSize gives the number of changes 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
changeCacheSize to something like 10,000 isn't unreasonable.