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.

At the beginning of the step, the renderable attributes are rendered against the properties.
There is a slight delay however when those are not yet rendered, which lead to weird and difficult to reproduce bugs.
To address this problem, a rendered attribute is available for methods that could be called early in the buildstep creation.

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.

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

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

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.

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.

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 worker is lost during step processing, a ConnectionLost failure.

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

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.

Returns a dictionary containing status information for a running step.
The dictionary can have 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".

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.
The step’s result is available in self.results at that time.

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

Returns a dictionary containing status information for a completed step.
This method calls getResultSummary, and automatically compute a build key from the step key according to the updateBuildSummaryPolicy

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.

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.

Fetch the version of the named command, as specified on the worker.
In practice, all commands on a worker have the same version, but passing command is still useful to ensure that the command is implemented on the worker.
If the command is not implemented on the worker, workerVersion 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, workerVersion will return oldVersion.
Since such ancient versions of Buildbot are no longer in use, this functionality is largely vestigial.

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

The BuildStep class provides methods to add log data to the step.
Subclasses provide a great deal of user-configurable functionality on top of these methods.
These methods can be called while the step is running, but not before.

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.

If the logfile’s content is a bytestring, it is decoded with the step’s log encoding or the global default log encoding.
To add a logfile with a different character encoding, perform the decode operation directly and pass the resulting unicode string to this method.

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:

classMyStep(LoggingBuildStep):logfiles=dict(debug='debug.log')

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

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.

Most Buildbot steps run shell commands on the worker, 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 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.

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 worker capabilities before creating the command.
It takes care of just about everything:

The ShellMixin class implements getResultSummary, returning a summary of the command.
If no command was specified or run, it falls back to the default getResultSummary based on descriptionDone.
Subclasses can override this method to return a more appropriate status.