Skip to content

Latest commit

 

History

History
491 lines (332 loc) · 17.5 KB

0.9-worker-transition.rst

File metadata and controls

491 lines (332 loc) · 17.5 KB
Raw

Transition to "worker" terminology in BuildBot 0.9.0

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. The fallbacks have been removed in Buildbot version 2.0.0.

Old names fallback settings

Use of obsolete names will raise Python warnings with category :py:exc:`buildbot.worker_transition.DeprecatedWorkerAPIWarning`. By default these warnings are printed in the application log. This behaviour can be changed by setting appropriate Python warnings settings via Python's :py:mod:`warnings` module:

import warnings
from buildbot.worker_transition import DeprecatedWorkerAPIWarning
# Treat old-name usage as errors:
warnings.simplefilter("error", DeprecatedWorkerAPIWarning)

See Python's :py:mod:`warnings` module documentation for complete list of available actions, in particular warnings can be disabled using "ignore" action.

It's recommended to configure warnings inside :file:`buildbot.tac`, before using any other Buildbot classes.

Changed API

In general "Slave" and "Buildslave" parts in identifiers and messages were replaced with "Worker"; "SlaveBuilder" with "WorkerForBuilder".

Below is the list of changed API (use of old names from this list will work). Note that some of these symbols are not included in Buildbot's public API. Compatibility is provided as a convenience to those using the private symbols anyway.

Plugins

buildbot.buildslave entry point was renamed to buildbot.worker, new plugins should be updated accordingly.

Plugins that use old buildbot.buildslave entry point are still available in the configuration file in the same way, as they were in versions prior 0.9.0:

from buildbot.plugins import buildslave  # deprecated, use "worker" instead
w = buildslave.ThirdPartyWorker()

But also they available using new namespace inside configuration file, so its recommended to use buildbot.plugins.worker name even if plugin uses old entry points:

from buildbot.plugins import worker
# ThirdPartyWorker can be defined in using `buildbot.buildslave` entry
# point, this still will work.
w = worker.ThirdPartyWorker()

Other changes:

  • buildbot.plugins.util.BuildslaveChoiceParameter is deprecated in favor of WorkerChoiceParameter.
  • buildbot.plugins.util.enforceChosenSlave is deprecated in favor of enforceChosenWorker.
  • buildbot.plugins.util.SlaveLock is deprecated in favor of WorkerLock.

BuildmasterConfig changes

  • c['slaves'] was replaced with c['workers']. Use of c['slaves'] will work, but is considered deprecated, and will be removed in the future versions of Buildbot.
  • Configuration key c['slavePortnum'] is deprecated in favor of c['protocols']['pb']['port'].

Docker latent worker changes

In addition to class being renamed, environment variables that are set inside container SLAVENAME and SLAVEPASS were renamed to WORKERNAME and WORKERPASS accordingly. Old environment variable are still available, but are deprecated and will be removed in the future.

EC2 latent worker changes

Use of default values of keypair_name and security_name constructor arguments of :py:class:`buildbot.worker.ec2.EC2LatentWorker` is deprecated. Please specify them explicitly.

steps.slave.SetPropertiesFromEnv changes

In addition to buildbot.steps.slave module being renamed to :py:mod:`buildbot.steps.worker`, default source value for :py:class:`~buildbot.steps.worker.SetPropertiesFromEnv` was changed from "SlaveEnvironment" to "WorkerEnvironment".

Local worker changes

Working directory for local workers were changed from master-basedir/slaves/name to master-basedir/workers/name.

Worker Manager changes

slave_config function argument was renamed to worker_config.

Properties

Metrics

Renamed events:

Old name New name
AbstractBuildSlave.attached_slaves AbstractWorker.attached_workers
BotMaster.attached_slaves BotMaster.attached_workers
BotMaster.slaveLost() BotMaster.workerLost()
BotMaster.getBuildersForSlave() BotMaster.getBuildersForWorker()
AttachedSlavesWatcher AttachedWorkersWatcher
attached_slaves attached_workers

Database

Schema changes:

Old name New name
buildslaves table workers
builds.buildslaveid (not ForeignKey) column workerid (now ForeignKey)
configured_buildslaves table configured_workers
configured_buildslaves.buildslaveid (ForeignKey) column workerid
connected_buildslaves table connected_workers
connected_buildslaves.buildslaveid (ForeignKey) column workerid
buildslaves_name index workers_name
configured_slaves_buildmasterid index configured_workers_buildmasterid
configured_slaves_slaves index configured_workers_workers
configured_slaves_identity index configured_workers_identity
connected_slaves_masterid index connected_workers_masterid
connected_slaves_slaves index connected_workers_workers
connected_slaves_identity index connected_workers_identity
builds_buildslaveid index builds_workerid

List of database-related changes in API (fallback for old API is provided):

usePTY changes

usePTY default value has been changed from slave-config to None (use of slave-config will still work, but discouraged).

buildbot-worker

buildbot-slave package has been renamed to buildbot-worker.

buildbot-worker has backward incompatible changes and requires buildmaster >= 0.9.0b8. buildbot-slave from 0.8.x will work with both 0.8.x and 0.9.x versions of buildmaster, so there is no need to upgrade currently deployed buildbot-slaves during switch from 0.8.x to 0.9.x.

Master/worker compatibility table
  master 0.8.x master 0.9.x
buildbot-slave yes yes
buildbot-worker no yes

buildbot-worker doesn't support worker-side specification of usePTY (with --usepty command line switch of buildbot-worker create-worker), you need to specify this option on master side.

getSlaveInfo remote command was renamed to getWorkerInfo in buildbot-worker.