BuildSteps

There are a few parent classes that are used as base classes for real buildsteps. This section describes the base classes. The "leaf" classes are described in Build Steps.

BuildStep

class buildbot.process.buildstep.BuildStep(name, description, descriptionDone, descriptionSuffix, locks, haltOnFailure, flunkOnWarnings, flunkOnFailure, warnOnWarnings, warnOnFailure, alwaysRun, progressMetrics, useProgress, doStepIf, hideStepIf)

All constructor arguments must be given as keyword arguments. Each constructor parameter is copied to the corresponding attribute.

name

The name of the step.

description

The description of the step.

descriptionDone

The description of the step after it has finished.

descriptionSuffix

Any extra information to append to the description.

locks

List of locks for this step; see Interlocks.

progressMetrics

List of names of metrics that should be used to track the progress of this build, and build ETA's for users. This is generally set in the

useProgress

If true (the default), then ETAs will be calculated for this step using progress metrics. If the step is known to have unpredictable timing (e.g., an incremental build), then this should be set to false.

doStepIf

A callable or bool to determine whether this step should be executed. See Common Parameters for details.

hideStepIf

A callable or bool to determine whether this step should be shown in the waterfall and build details pages. See Common Parameters for details.

The following attributes affect the behavior of the containing build:

haltOnFailure

If true, the build will halt on a failure of this step, and not execute subsequent tests (except those with alwaysRun).

flunkOnWarnings

If true, the build will be marked as a failure if this step ends with warnings.

flunkOnFailure

If true, the build will be marked as a failure if this step fails.

warnOnWarnings

If true, the build will be marked as warnings, or worse, if this step ends with warnings.

warnOnFailure

If true, the build will be marked as warnings, or worse, if this step fails.

alwaysRun

If true, the step will run even if a previous step halts the build with haltOnFailure.

A few important pieces of information are not available when a step is constructed, and are added later. These are set by the following methods; the order in which these methods are called is not defined.

setBuild(build)
Parameters:build -- the Build instance controlling this step.

This method is called during setup to set the build instance controlling this slave. Subclasses can override this to get access to the build object as soon as it is available. The default implementation sets the build attribute.

build

The build object controlling this step.

setBuildSlave(build)
Parameters:build -- the BuildSlave instance on which this step will run.

Similarly, this method is called with the build slave that will run this step. The default implementation sets the buildslave attribute.

buildslave

The build slave that will run this step.

setDefaultWorkdir(workdir)
Parameters:workdir -- the default workdir, from the build

This method is called at build startup with the default workdir for the build. Steps which allow a workdir to be specified, but want to override it with the build's default workdir, can use this method to apply the default.

setupProgress()

This method is called during build setup to give the step a chance to set up progress tracking. It is only called if the build has useProgress set. There is rarely any reason to override this method.

progress

If the step is tracking progress, this is a StepProgress instance performing that task.

Execution of the step itself is governed by the following methods and attributes.

startStep(remote)
Parameters:remote -- a remote reference to the slave-side SlaveBuilder instance
Returns:Deferred

Begin the step. This is the build's interface to step execution. Subclasses should override run to implement custom behaviors.

run()
Returns:result via Deferred

Execute the step. When this method returns (or when the Deferred it returns fires), the step is complete. The method's return value must be an integer, giving the result of the step -- a constant from buildbot.status.results. If the method raises an exception or its Deferred fires with failure, then the step will be completed with an EXCEPTION result. Any other output from the step (logfiles, status strings, URLs, etc.) is the responsibility of the run method.

Subclasses should override this method. Do not call finished or failed from this method.

start()
Returns:None or SKIPPED, optionally via a Deferred.

Begin the step. BuildSteps written before Buildbot-0.9.0 often override this method instead of run, but this approach is deprecated.

When the step is done, it should call finished, with a result -- a constant from buildbot.status.results. The result will be handed off to the Build.

If the step encounters an exception, it should call failed with a Failure object.

If the step decides it does not need to be run, start can return the constant SKIPPED. In this case, it is not necessary to call finished directly.

finished(results)
Parameters:results -- a constant from results

A call to this method indicates that the step is finished and the build should analyze the results and perhaps proceed to the next step. The step should not perform any additional processing after calling this method. This method must only be called from the (deprecated) start method.

failed(failure)
Parameters:failure -- a Failure instance

Similar to finished, this method indicates that the step is finished, but handles exceptions with appropriate logging and diagnostics.

This method handles BuildStepFailed specially, by calling finished(FAILURE). This provides subclasses with a shortcut to stop execution of a step by raising this failure in a context where failed will catch it. This method must only be called from the (deprecated) start method.

interrupt(reason)
Parameters:reason (string or Failure) -- why the build was interrupted

This method is used from various control interfaces to stop a running step. The step should be brought to a halt as quickly as possible, by cancelling a remote command, killing a local process, etc. The step must still finish with either finished or failed.

The reason parameter can be a string or, when a slave is lost during step processing, a ConnectionLost failure.

The parent method handles any pending lock operations, and should be called by implementations in subclasses.

stopped

If false, then the step is running. If true, the step is not running, or has been interrupted.

A step can indicate its up-to-the-moment status using a short summary string. These methods allow step subclasses to produce such summaries.

updateSummary()

Update the summary, calling getCurrentSummary or getResultSummary as appropriate. New-style build steps should call this method any time the summary may have changed. This method is debounced, so even calling it for every log line is acceptable.

getCurrentSummary()
Returns:dictionary, optionally via Deferred

Returns a dictionary containing status information for a running step. The dictionary can a step key with a unicode value giving a summary for display with the step. This method is only called while the step is running.

New-style build steps should override this method to provide a more interesting summary than the default u"running".

getResultSummary()
Returns:dictionary, optionally via Deferred

Returns a dictionary containing status information for a completed step. The dictionary can have keys step and build, each with unicode values. The step key gives a summary for display with the step, while the build key gives a summary for display with the entire build. The latter should be used sparingly, and include only information that the user would find relevant for the entire build, such as a number of test failures. Either or both keys can be omitted.

This method is only called while the step is finished.

New-style build steps should override this method to provide a more interesting summary than the default u"running", or to provide any build summary information.

describe(done=False)
Parameters:done -- If true, the step is finished.
Returns:list of strings

Describe the step succinctly. The return value should be a sequence of short strings suitable for display in a horizontally constrained space.

Note

Be careful not to assume that the step has been started in this method. In relatively rare circumstances, steps are described before they have started. Ideally, unit tests should be used to ensure that this method is resilient.

Note

This method is not called for new-style steps. Instead, override getCurrentSummary and getResultSummary.

Build steps have statistics, a simple key/value store of data which can later be aggregated over all steps in a build. Note that statistics are not preserved after a build is complete.

hasStatistic(stat)
Parameters:stat (string) -- name of the statistic
Returns:True if the statistic exists on this step
getStatistic(stat, default=None)
Parameters:
  • stat (string) -- name of the statistic
  • default -- default value if the statistic does not exist
Returns:

value of the statistic, or the default value
getStatistics()
Returns:a dictionary of all statistics for this step
setStatistic(stat, value)
Parameters:
  • stat (string) -- name of the statistic
  • value -- value to assign to the statistic
Returns:

value of the statistic

Build steps support progress metrics - values that increase roughly linearly during the execution of the step, and can thus be used to calculate an expected completion time for a running step. A metric may be a count of lines logged, tests executed, or files compiled. The build mechanics will take care of translating this progress information into an ETA for the user.

setProgress(metric, value)
Parameters:
  • metric (string) -- the metric to update
  • value (integer) -- the new value for the metric

Update a progress metric. This should be called by subclasses that can provide useful progress-tracking information.

The specified metric name must be included in progressMetrics.

The following methods are provided as utilities to subclasses. These methods should only be invoked after the step is started.

slaveVersion(command, oldversion=None)
Parameters:
  • command (string) -- command to examine
  • oldversion -- return value if the slave does not specify a version
Returns:

string

Fetch the version of the named command, as specified on the slave. In practice, all commands on a slave have the same version, but passing command is still useful to ensure that the command is implemented on the slave. If the command is not implemented on the slave, slaveVersion will return None.

Versions take the form x.y where x and y are integers, and are compared as expected for version numbers.

Buildbot versions older than 0.5.0 did not support version queries; in this case, slaveVersion will return oldVersion. Since such ancient versions of Buildbot are no longer in use, this functionality is largely vestigial.

slaveVersionIsOlderThan(command, minversion)
Parameters:
  • command (string) -- command to examine
  • minversion -- minimum version
Returns:

boolean

This method returns true if command is not implemented on the slave, or if it is older than minversion.

getSlaveName()
Returns:string

Get the name of the buildslave assigned to this step.

Most steps exist to run commands. While the details of exactly how those commands are constructed are left to subclasses, the execution of those commands comes down to this method:

runCommand(command)
Parameters:command -- RemoteCommand instance
Returns:Deferred

This method connects the given command to the step's buildslave and runs it, returning the Deferred from run.

addURL(name, url)
Parameters:
  • name -- URL name
  • url -- the URL

Add a link to the given url, with the given name to displays of this step. This allows a step to provide links to data that is not available in the log files.

The BuildStep class provides minimal support for log handling, that is extended by the LoggingBuildStep class. The following methods provide some useful behaviors. These methods can be called while the step is running, but not before.

addLog(name)
Parameters:name -- log name
Returns:LogFile instance via Deferred

Add a new logfile with the given name to the step, and return the log file instance.

getLog(name)
Parameters:name -- log name
Returns:LogFile instance
Raises:KeyError if the log is not found

Get an existing logfile by name.

addCompleteLog(name, text)
Parameters:
  • name -- log name
  • text -- content of the logfile
Returns:

Deferred

This method adds a new log and sets text as its content. This is often useful to add a short logfile describing activities performed on the master. The logfile is immediately closed, and no further data can be added.

addHTMLLog(name, html)
Parameters:
  • name -- log name
  • html -- content of the logfile
Returns:

Deferred

Similar to addCompleteLog, this adds a logfile containing pre-formatted HTML, allowing more expressiveness than the text format supported by addCompleteLog.

addLogObserver(logname, observer)
Parameters:
  • logname -- log name
  • observer -- log observer instance

Add a log observer for the named log. The named log need not have been added already: the observer will be connected when the log is added.

See Adding LogObservers for more information on log observers.

LoggingBuildStep

class buildbot.process.buildstep.LoggingBuildStep(logfiles, lazylogfiles, log_eval_func, name, locks, haltOnFailure, flunkOnWarnings, flunkOnFailure, warnOnWarnings, warnOnFailure, alwaysRun, progressMetrics, useProgress, doStepIf, hideStepIf)
Parameters:

The remaining arguments are passed to the BuildStep constructor.

Warning

Subclasses of this class are always old-style steps. As such, this class will be removed after Buildbot-0.9.0. Instead, subclass BuildStep and mix in ShellMixin to get similar behavior.

This subclass of BuildStep is designed to help its subclasses run remote commands that produce standard I/O logfiles. It:

  • tracks progress using the length of the stdout logfile
  • provides hooks for summarizing and evaluating the command's result
  • supports lazy logfiles
  • handles the mechanics of starting, interrupting, and finishing remote commands
  • detects lost slaves and finishes with a status of RETRY
logfiles

The logfiles to track, as described for ShellCommand. The contents of the class-level logfiles attribute are combined with those passed to the constructor, so subclasses may add log files with a class attribute:

class MyStep(LoggingBuildStep):
    logfiles = dict(debug='debug.log')

Note that lazy logfiles cannot be specified using this method; they must be provided as constructor arguments.

startCommand(command)
Parameters:command -- the RemoteCommand instance to start

Note

This method permits an optional errorMessages parameter, allowing errors detected early in the command process to be logged. It will be removed, and its use is deprecated.

Handle all of the mechanics of running the given command. This sets up all required logfiles, keeps status text up to date, and calls the utility hooks described below. When the command is finished, the step is finished as well, making this class is unsuitable for steps that run more than one command in sequence.

Subclasses should override start and, after setting up an appropriate command, call this method.

def start(self):
    cmd = RemoteShellCommand(...)
    self.startCommand(cmd, warnings)

To refine the status output, override one or more of the following methods. The LoggingBuildStep implementations are stubs, so there is no need to call the parent method.

commandComplete(command)
Parameters:command -- the just-completed remote command

This is a general-purpose hook method for subclasses. It will be called after the remote command has finished, but before any of the other hook functions are called.

createSummary(stdio)
Parameters:stdio -- stdio LogFile

This hook is designed to perform any summarization of the step, based either on the contents of the stdio logfile, or on instance attributes set earlier in the step processing. Implementations of this method often call e.g., addURL.

evaluateCommand(command)
Parameters:command -- the just-completed remote command
Returns:step result from buildbot.status.results

This hook should decide what result the step should have. The default implementation invokes log_eval_func if it exists, and looks at rc to distinguish SUCCESS from FAILURE.

The remaining methods provide an embarrassment of ways to set the summary of the step that appears in the various status interfaces. The easiest way to affect this output is to override describe. If that is not flexible enough, override getText and/or getText2.

getText(command, results)
Parameters:
  • command -- the just-completed remote command
  • results -- step result from evaluateCommand
Returns:

a list of short strings

This method is the primary means of describing the step. The default implementation calls describe, which is usually the easiest method to override, and then appends a string describing the step status if it was not successful.

getText2(command, results)
Parameters:
  • command -- the just-completed remote command
  • results -- step result from evaluateCommand
Returns:

a list of short strings

Like getText, this method summarizes the step's result, but it is only called when that result affects the build, either by making it halt, flunk, or end with warnings.

CommandMixin

The runCommand method can run a RemoteCommand instance, but it's no help in building that object or interpreting the results afterward. This mixin class adds some useful methods for running commands.

This class can only be used in new-style steps.

class buildbot.process.buildstep.CommandMixin

Some remote commands are simple enough that they can boil down to a method call. Most of these take an abandonOnFailure argument which, if true, will abandon the entire buildstep on command failure. This is accomplished by raising BuildStepFailed.

These methods all write to the stdio log (generally just for errors). They do not close the log when finished.

runRmdir(dir, abandonOnFailure=True)
Parameters:
  • dir -- directory to remove
  • abndonOnFailure -- if true, abandon step on failure
Returns:

Boolean via Deferred

Remove the given directory, using the rmdir command. Returns False on failure.

runMkdir(dir, abandonOnFailure=True)
Parameters:
  • dir -- directory to create
  • abndonOnFailure -- if true, abandon step on failure
Returns:

Boolean via Deferred

Create the given directory and any parent directories, using the mkdir command. Returns False on failure.

pathExists(path)

:param path path to test :returns: Boolean via Deferred

Determine if the given path exists on the slave (in any form - file, directory, or otherwise). This uses the stat command.

glob(path)

:param path path to test :returns: list of filenames

Get the list of files matching the given path pattern on the slave. This uses Python's glob module. If the glob method fails, it aborts the step.

ShellMixin

Most Buildbot steps run shell commands on the slave, and Buildbot has an impressive array of configuration parameters to control that execution. The ShellMixin mixin provides the tools to make running shell commands easy and flexible.

This class can only be used in new-style steps.

class buildbot.process.buildstep.ShellMixin

This mixin manages the following step configuration parameters, the contents of which are documented in the manual. Naturally, all of these are renderable.

..py:attribute:: command ..py:attribute:: workdir ..py:attribute:: env ..py:attribute:: want_stdout ..py:attribute:: want_stderr ..py:attribute:: usePTY ..py:attribute:: logfiles ..py:attribute:: lazylogfiles ..py:attribute:: timeout ..py:attribute:: maxTime ..py:attribute:: logEnviron ..py:attribute:: interruptSignal ..py:attribute:: sigtermTime ..py:attribute:: initialStdin ..py:attribute:: decodeRC

..py:method:: setupShellMixin(constructorArgs, prohibitArgs=[])

:param dict constructorArgs constructor keyword arguments :param list prohibitArgs list of recognized arguments to reject :returns: keyword arguments destined for BuildStep

This method is intended to be called from the shell constructor, passed any keyword arguments not otherwise used by the step. Any attributes set on the instance already (e.g., class-level attributes) are used as defaults. Attributes named in prohibitArgs are rejected with a configuration error.

The return value should be passed to the BuildStep constructor.

..py:method:: makeRemoteShellCommand(collectStdout=False, collectStderr=False, **overrides)

param collectStdout:
 if true, the command's stdout wil be available in cmd.stdout on completion
param collectStderr:
 if true, the command's stderr wil be available in cmd.stderr on completion
param overrides:
 overrides arguments that might have been passed to setupShellMixin
returns:RemoteShellCommand instance via Deferred

This method constructs a RemoteShellCommand instance based on the instance attributes and any supplied overrides. It must be called while the step is running, as it examines the slave capabilities before creating the command. It takes care of just about everything:

  • Creating log files and associating them with the command
  • Merging environment configuration
  • Selecting the appropriate workdir configuration

All that remains is to run the command with runCommand.

Exceptions

exception buildbot.process.buildstep.BuildStepFailed

This exception indicates that the buildstep has failed. It is useful as a way to skip all subsequent processing when a step goes wrong. It is handled by BuildStep.failed.