4.5.5 Data Lifetime

     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.

The 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.

The 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 than logHorizon but not older than buildHorizon will maintain their overall status and the status of each step, but the logfiles will be deleted.

The 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.

Finally, the 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 setting changeCacheSize to something like 10,000 isn't unreasonable.