Buildbot Manual

RemiZOffAlex  Создано: 2018-02-05 14:02:33.712612  Обновлено: 2018-02-05 14:02:33.712618


Buildbot is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure. The guilty developer can be identified and harassed without human intervention. By running the builds on a variety of platforms, developers who do not have the facilities to test their changes everywhere before checkin will at least know shortly afterwards whether they have broken the build or not. Warning counts, lint checks, image size, compile time, and other build parameters can be tracked over time, are more visible, and are therefore easier to improve.

The overall goal is to reduce tree breakage and provide a platform to run tests or code-quality checks that are too annoying or pedantic for any human to waste their time with. Developers get immediate (and potentially public) feedback about their changes, encouraging them to be more careful about testing before checkin.


  • run builds on a variety of worker platforms
  • arbitrary build process: handles projects using C, Python, whatever
  • minimal host requirements: Python and Twisted
  • workers can be behind a firewall if they can still do checkout
  • status delivery through web page, email, IRC, other protocols
  • track builds in progress, provide estimated completion time
  • flexible configuration by subclassing generic build process classes
  • debug tools to force a new build, submit fake Changes, query worker status
  • released under the GPL


2.3 Концепт

This chapter defines some of the basic concepts that the Buildbot uses. You’ll need to understand how the Buildbot sees the world to configure it properly.

В этой главе определяются некоторые из основных концепций, которые использует Buildbot. Вам нужно понять, как Buildbot видит мир, чтобы правильно его настроить.

Secret Management

2.5 Настройка

The following sections describe the configuration of the various Buildbot components. The information available here is sufficient to create basic build and test configurations, and does not assume great familiarity with Python.

В следующих разделах описывается конфигурация различных компонентов Buildbot. Информация, доступная здесь, достаточна для создания базовых конфигураций сборки и тестирования и не предполагает глубокого знакомства с Python.

In more advanced Buildbot configurations, Buildbot acts as a framework for a continuous-integration application. The next section, Customization, describes this approach, with frequent references into the development documentation.

Transition to “worker” terminology

Since version 0.9.0 of Buildbot “slave”-based terminology is deprecated in favor of “worker”-based terminology.

API change is done in backward compatible way, so old “slave”-containing classes, functions and attributes are still available and can be used. Old API support will be removed in the future versions of Buildbot.

Rename of API introduced in beta versions of Buildbot 0.9.0 done without providing fallback. See release notes for the list of breaking changes of private interfaces.


For advanced users, Buildbot acts as a framework supporting a customized build application. For the most part, such configurations consist of subclasses set up for use in a regular Buildbot configuration file.

This chapter describes some of the more common idioms in advanced Buildbot configurations.

At the moment, this chapter is an unordered set of suggestions:

If you’d like to clean it up, fork the project on GitHub and get started!

New-Style Build Steps

In Buildbot-0.9.0, many operations performed by BuildStep subclasses return a Deferred. As a result, custom build steps which call these methods will need to be rewritten.

Buildbot-0.8.9 supports old-style steps natively, while new-style steps are emulated. Buildbot-0.9.0 supports new-style steps natively, while old-style steps are emulated. Later versions of Buildbot will not support old-style steps at all. All custom steps should be rewritten in the new style as soon as possible.

Buildbot distinguishes new-style from old-style steps by the presence of a run method. If this method is present, then the step is a new-style step.

Command-line Tool

This section describes command-line tools available after buildbot installation. Since version 0.8 the one-for-all buildbot command-line tool was divided into two parts namely buildbot and buildslave, starting from version 0.9 buildslave command was replaced with buildbot-worker command. The last one was separated from main command-line tool to minimize dependencies required for running a worker while leaving all other functions to buildbot tool.

Every command-line tool has a list of global options and a set of commands which have their own options. One can run these tools in the following way:

buildbot [global options] command [command options]
buildbot-worker [global options] command [command options]

The buildbot command is used on the master, while buildbot-worker is used on the worker. Global options are the same for both tools which perform the following actions:

--help Print general help about available commands and global options and exit. All subsequent arguments are ignored.
--verbose Set verbose output.
--version Print current buildbot version and exit. All subsequent arguments are ignored.

You can get help on any command by specifying --help as a command option:

buildbot command --help

You can also use manual pages for buildbot and buildbot-worker for quick reference on command-line options.

The remainder of this section describes each buildbot command. See Command Line Index for a full list.


The Buildbot home page is

For configuration questions and general discussion, please use the buildbot-devel mailing list. The subscription instructions and archives are available at

The #buildbot channel on Freenode’s IRC servers hosts development discussion, and often folks are available to answer questions there, as well.


If you’re feeling your Buildbot is running a bit slow, here are some tricks that may help you, but use them at your own risk.

Plugin Infrastructure in Buildbot

New in version 0.8.11.

Plugin infrastructure in Buildbot allows easy use of components that are not part of the core. It also allows unified access to components that are included in the core.

The following snippet

from buildbot.plugins import kind

... kind.ComponentClass ...

allows to use a component of kind kind. Available kinds are:

workers, described in Workers
change source, described in Change Sources
schedulers, described in Schedulers
build steps, described in Build Steps
reporters (or reporter targets), described in Reporters
utility classes. For example, BuilderConfigBuild FactoriesChangeFilter and Locks are accessible through util.

Web interface plugins are not used directly: as described in web server configuration section, they are listed in the corresponding section of the web server configuration dictionary.


If you are not very familiar with Python and you need to use different kinds of components, start your master.cfg file with:

from buildbot.plugins import *

As a result, all listed above components will be available for use. This is what sample master.cfgfile uses.


This page aims at describing the common pitfalls and best practices when deploying buildbot.


© RemiZOffAlex