Navigation

In Buildbot-0.9.0, many operations performed by BuildStep subclasses return a Deferred.
As a result, custom build steps which call these methods will need to be rewritten.

Buildbot-0.8.9 supports old-style steps natively, while new-style steps are emulated.
Buildbot-0.9.0 supports new-style steps natively, while old-style steps are emulated.
Later versions of Buildbot will not support old-style steps at all.
All custom steps should be rewritten in the new style as soon as possible.

Buildbot distinguishes new-style from old-style steps by the presence of a run method.
If this method is present, then the step is a new-style step.

New-style steps have a run method that is simpler to implement than the old start method.

Many methods are now asynchronous (return Deferreds), as they perform operations on the database.

Logs are now implemented by a completely different class.
This class supports the same log-writing methods (addStderr and so on), although they are now asynchronous.
However, it does not support log-reading methods such as getText.
It was never advisable to handle logs as enormous strings.
New-style steps should, instead, use a LogObserver or (in Buildbot-0.9.0) fetch log lines bit by bit using the data API.

Step strings, derived by parameters like description, descriptionDone, and descriptionSuffix, are no longer treated as lists.
For backward compatibility, the parameters may still be given as lists, but will be joined with spaces during execution (using join_list).

Some hacks are in place to support old-style steps.
These hacks are only activated when an old-style step is detected.
Support for old-style steps will be dropped soon after Buildbot-0.9.0 is released.

The Deferreds from all asynchronous methods invoked during step execution are gathered internally.
The step is not considered finished until all such Deferreds have fired, and is marked EXCEPTION if any fail.
For logfiles, this is accomplished by means of a synchronous wrapper class.

Logfile data is available while the step is still in memory.
This means that logs returned from step.getLog have the expected methods getText, readlines and so on.

ShellCommand subclasses implicitly gather all stdio output in memory and provide it to the createSummary method.

If your custom buildstep implements the start method, then rename that method to run and set it up to return a Deferred, either explicitly or via inlineCallbacks.
The value of the Deferred should be the result of the step (one of the codes in buildbot.process.results), or a Twisted failure instance to complete the step as EXCEPTION.
The new run method should not call self.finished or self.failed, instead signalling the same via Deferred.

For example, the following old-style start method

defstart(self):## old stylecmd=remotecommand.RemoteCommand('stat',{'file':self.file})d=self.runCommand(cmd)d.addCallback(lambdares:self.convertResult(cmd))d.addErrback(self.failed)

Becomes

@defer.inlineCallbacksdefrun(self):## new stylecmd=remotecommand.RemoteCommand('stat',{'file':self.file})yieldself.runCommand(cmd)defer.returnValue(self.convertResult(cmd))

Is a synchronous function, not returning a Deferred.
However, when converted to a new-style test, it must handle Deferreds from the methods it calls, so it must be asynchronous.
Syntactically, inlineCallbacks makes the change fairly simple:

Good news!
The API for properties is the same synchronous API as was available in old-style steps.
Properties are handled synchronously during the build, and persisted to the database at completion of each step.

All of these methods now return Deferreds.
None of the old log-reading methods are available on this object:

hasContents

getText

readLines

getTextWithHeaders

getChunks

If your step uses such methods, consider using a LogObserver instead, or using the Data API to get the required data.

The undocumented and unused subscribeConsumer method of logfiles has also been removed.

The subscribe method now takes a callable, rather than an instance, and does not support catchup.
This method was primarily used by LogObserver, the implementation of which has been modified accordingly.
Any other uses of the subscribe method should be refactored to use a LogObserver.