SpecialistOff.NET / Вопросы / Статьи / Фрагменты кода / Резюме / Метки / Помощь / Файлы
НазадМетки: buildbot
Each Buildmaster has a set of scheduler objects, each of which gets a copy of every incoming Change
. The Schedulers are responsible for deciding when Build
s should be run. Some Buildbot installations might have a single scheduler, while others may have several, each for a different purpose.
For example, a quick scheduler might exist to give immediate feedback to developers, hoping to catch obvious problems in the code that can be detected quickly. These typically do not run the full test suite, nor do they run on a wide variety of platforms. They also usually do a VC update rather than performing a brand-new checkout each time.
A separate full scheduler might run more comprehensive tests, to catch more subtle problems. It might be configured to run after the quick scheduler, to give developers time to commit fixes to bugs caught by the quick scheduler before running the comprehensive tests. This scheduler would also feed multiple Builder
s.
Many schedulers can be configured to wait a while after seeing a source-code change - this is the tree stable timer. The timer allows multiple commits to be “batched” together. This is particularly useful in distributed version control systems, where a developer may push a long sequence of changes all at once. To save resources, it’s often desirable only to test the most recent change.
Schedulers can also filter out the changes they are interested in, based on a number of criteria. For example, a scheduler that only builds documentation might skip any changes that do not affect the documentation. Schedulers can also filter on the branch to which a commit was made.
There is some support for configuring dependencies between builds - for example, you may want to build packages only for revisions which pass all of the unit tests. This support is under active development in Buildbot, and is referred to as “build coordination”.
Periodic builds (those which are run every N seconds rather than after new Changes arrive) are triggered by a special Periodic
scheduler.
Each scheduler creates and submits BuildSet
objects to the BuildMaster
, which is then responsible for making sure the individual BuildRequests
are delivered to the target Builder
s.
Scheduler instances are activated by placing them in the schedulers
list in the buildmaster config file. Each scheduler must have a unique name.