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.
Ключи в этом разделе влияют на работу buildmaster в глобальном масштабе.
Change is an abstract way Buildbot uses to represent a single change to the source files performed by a developer. In version control systems that support the notion of atomic check-ins, a change represents a changeset or commit. Instances of
Change have the following attributes.
A change source is the mechanism which is used by Buildbot to get information about new changes in a repository maintained by a Version Control System.
These change sources fall broadly into two categories: pollers which periodically check the repository for updates; and hooks, where the repository is configured to notify Buildbot whenever an update occurs.
Change is an abstract way that Buildbot uses to represent changes in any of the Version Control Systems it supports. It contains just enough information needed to acquire specific version of the tree when needed. This usually happens as one of the first steps in a
This concept does not map perfectly to every version control system. For example, for CVS, Buildbot must guess that version updates made to multiple files within a short time represent a single change.
Changes can be provided by a variety of
ChangeSource types, although any given project will typically have only a single
Планировщики несут ответственность за запуск сборок на сборщиках.
Некоторые планировщики отслеживают изменения из ChangeSources и создают наборы сборки в ответ на эти изменения. Другие генерируют наборы сборки без изменений на основе других событий в buildmaster.
workers configuration key specifies a list of known workers. In the common case, each worker is defined by an instance of the
buildbot.worker.Worker class. It represents a standard, manually started machine that will try to connect to the Buildbot master as a worker. Buildbot also supports “on-demand”, or latent, workers, which allow Buildbot to dynamically start and stop worker instances.
The buildbot’s behavior is defined by the config file, which normally lives in the
master.cfg file in the buildmaster’s base directory (but this can be changed with an option to the buildbot create-mastercommand). This file completely specifies which
Builders are to be run, which workers they should use, how
Changes should be tracked, and where the status information is to be sent. The buildmaster’s
buildbot.tac file names the base directory; everything else comes from the config file.
A sample config file was installed for you when you created the buildmaster, but you will need to edit it before your buildbot will do anything useful.
This chapter gives an overview of the format of this file and the various sections in it. You will need to read the later chapters to understand how to fill in each section properly.