3.2 Scheduling Builds

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 Builds 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, 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
Builders.

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

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

Scheduler instances are activated by placing them in the
c['schedulers'] list in the buildmaster config file. Each
Scheduler has a unique name.