SpecialistOff.NET / Вопросы / Статьи / Фрагменты кода / Резюме / Метки / Помощь / Файлы

2.5.5.1. Настройка планировщиков

Метки: buildbot

The schedulers configuration parameter gives a list of scheduler instances, each of which causes builds to be started on a particular set of Builders. The two basic scheduler classes you are likely to start with are SingleBranchScheduler and Periodic, but you can write a customized subclass to implement more complicated build scheduling.

Scheduler arguments should always be specified by name (as keyword arguments), to allow for future expansion:

sched = SingleBranchScheduler(name="quick", builderNames=['lin', 'win'])

There are several common arguments for schedulers, although not all are available with all schedulers.

name

Each Scheduler must have a unique name. This is used in status displays, and is also available in the build property scheduler.

builderNames

This is the set of builders which this scheduler should trigger, specified as a list of names (strings). This can also be an IRenderable object which will render to a list of builder names (or a list of IRenderable that will render to builder names).

Note

When builderNames is rendered, these additional Properties attributes are available:

master

A reference to the BuildMaster object that owns this scheduler. This can be used to access the data API.

sourcestamps

The list of sourcestamps that triggered the scheduler.

changes

The list of changes associated with the sourcestamps.

files

The list of modified files associated with the changes.

Any property attached to the change(s) that triggered the scheduler will be combined and available when rendering builderNames.

Here is a simple example:

from buildbot.plugins import util, schedulers

@util.renderer
def builderNames(props):
    builders = set()
    for f in props.files:
        if f.endswith('.rst'):
            builders.add('check_docs')
        if f.endswith('.c'):
            builders.add('check_code')
    return list(builders)

c['schedulers'] = [
    schedulers.AnyBranchScheduler(
        name='all',
        builderNames=builderNames,
    )
]

And a more complex one:

import fnmatch

from twisted.internet import defer

from buildbot.plugins import util, schedulers

@util.renderer
@defer.inlineCallbacks
def builderNames(props):
    # If "buildername_pattern" is defined with "buildbot sendchange",
    # check if the builder name matches it.
    pattern = props.getProperty('buildername_pattern')

    # If "builder_tags" is defined with "buildbot sendchange",
    # only schedule builders that have the specified tags.
    tags = props.getProperty('builder_tags')

    builders = []

    for b in (yield props.master.data.get(('builders',))):
        if pattern and not fnmatch.fnmatchcase(b['name'], pattern):
            continue
        if tags and not set(tags.split()).issubset(set(b['tags'])):
            continue
        builders.append(b['name'])

    return builders

c['schedulers'] = [
   schedulers.AnyBranchScheduler(
      name='matrix',
      builderNames=builderNames,
   )
]

properties (optional)

This is a dictionary specifying properties that will be transmitted to all builds started by this scheduler. The owner property may be of particular interest, as its contents (list) will be added to the list of “interested users” (Doing Things With Users) for each triggered build. For example:
sched = Scheduler(...,
    properties = {
        'owner': ['zorro@example.com', 'silver@example.com']
    })

codebases (optional)

Specifies codebase definitions that are used when the scheduler processes data from more than one repository at the same time.

The codebases parameter is only used to fill in missing details about a codebase when scheduling a build. For example, when a change to codebase A occurs, a scheduler must invent a sourcestamp for codebase B. Source steps that specify codebase B as their codebase will use the invented timestamp.

The parameter does not act as a filter on incoming changes – use a change filter for that purpose.

This parameter can be specified in two forms:

as a list of strings. This is the simplest form; use it if no special overrides are needed. In this form, just the names of the codebases are listed.

as a dictionary of dictionaries. In this form, the per-codebase overrides of repository, branch and revision can be specified.

Each codebase definition dictionary is a dictionary with any of the keys: repository, branch, revision. The codebase definitions are combined in a dictionary keyed by the name of the codebase.
codebases = {'codebase1': {'repository':'....',
                           'branch':'default',
                           'revision': None},
             'codebase2': {'repository':'....'} }

fileIsImportant (optional)

A callable which takes as argument a Change instance and returns True if the change is worth building, and False if it is not. Unimportant Changes are accumulated until the build is triggered by an important change. The default value of None means that all Changes are important.

change_filter (optional)

The change filter that will determine which changes are recognized by this scheduler (see Change Filters). Note that this is different from fileIsImportant; if the change filter filters out a change, the change is completely ignored by the scheduler. If a change is allowed by the change filter but is deemed unimportant, it will not cause builds to start but will be remembered and shown in status displays. The default value of None does not filter any changes at all.

onlyImportant (optional)

A boolean that, when True, only adds important changes to the buildset as specified in the fileIsImportant callable. This means that unimportant changes are ignored the same way a change_filter filters changes. The default value is False and only applies when fileIsImportant is given.

reason (optional)

A string that will be used as the reason for the triggered build. By default it lists the type and name of the scheduler triggering the build.

The remaining subsections represent a catalog of the available scheduler types. All these schedulers are defined in modules under buildbot.schedulers, and their docstrings are the best source of documentation on the arguments each one takes.