This page documents the latest, unreleased version of Buildbot. For documentation for released versions, see


The Buildmaster has a variety of ways to present build status to various users. Each such delivery method is a Reporter Target object in the configuration's services list. To add reporter targets, you just append more objects to this list:

c['services'] = []

m = reporters.MailNotifier(fromaddr="buildbot@localhost",

c['services'].append(reporters.IRC(host="", nick="bb",
                                  channels=[{"channel": "#example1"},
                                            {"channel": "#example2",
                                             "password": "somesecretpassword"}]))

Most reporter objects take a tags= argument, which can contain a list of tag names: in this case, it will only show status for Builders that contains the named tags.


Implementation Note

Each of these objects should be a service.BuildbotService which will be attached to the BuildMaster object when the configuration is processed.

The remainder of this section describes each built-in reporters. A full list of reporters is available in the Reporter Target Index.


class buildbot.reporter.mail.MailNotifier

The buildbot can send email when builds finish. The most common use of this is to tell developers when their change has caused the build to fail. It is also quite common to send a message to a mailing list (usually named builds or similar) about every build.

The MailNotifier status target is used to accomplish this. You configure it by specifying who mail should be sent to, under what circumstances mail should be sent, and how to deliver the mail. It can be configured to only send out mail for certain builders, and only send messages when the build fails, or when the builder transitions from success to failure. It can also be configured to include various build logs in each message.

If a proper lookup function is configured, the message will be sent to the "interested users" list (Doing Things With Users), which includes all developers who made changes in the build. By default, however, Buildbot does not know how to construct an email addressed based on the information from the version control system. See the lookup argument, below, for more information.

You can add additional, statically-configured, recipients with the extraRecipients argument. You can also add interested users by setting the owners build property to a list of users in the scheduler constructor (Configuring Schedulers).

Each MailNotifier sends mail to a single set of recipients. To send different kinds of mail to different recipients, use multiple MailNotifiers. TODO: or subclass MailNotifier and override getRecipients()

The following simple example will send an email upon the completion of each build, to just those developers whose Changes were included in the build. The email contains a description of the Build, its results, and URLs where more information can be obtained.

from buildbot.plugins import reporters
mn = reporters.MailNotifier(fromaddr="",

To get a simple one-message-per-build (say, for a mailing list), use the following form instead. This form does not send mail to individual developers (and thus does not need the lookup= argument, explained below), instead it only ever sends mail to the extra recipients named in the arguments:

mn = reporters.MailNotifier(fromaddr="",

If your SMTP host requires authentication before it allows you to send emails, this can also be done by specifying smtpUser and smtpPassword:

mn = reporters.MailNotifier(fromaddr="",
                            relayhost="", smtpPort=587,


If for some reaons you are not able to send a notification with TLS enabled and specified user name and password, you might want to use contrib/ to see if it works at all.

If you want to require Transport Layer Security (TLS), then you can also set useTls:

mn = reporters.MailNotifier(fromaddr="",
                            useTls=True, relayhost="",
                            smtpPort=587, smtpUser="",


If you see twisted.mail.smtp.TLSRequiredError exceptions in the log while using TLS, this can be due either to the server not supporting TLS or to a missing PyOpenSSL package on the buildmaster system.

In some cases it is desirable to have different information then what is provided in a standard MailNotifier message. For this purpose MailNotifier provides the argument messageFormatter (a function) which allows for the creation of messages with unique content.

For example, if only short emails are desired (e.g., for delivery to phones):

from buildbot.plugins import reporters, util
def messageFormatter(mode, name, build, results, master_status):
    result = util.Results[results]

    text = list()
    text.append("STATUS: %s" % result.title())
    return {
        'body' : "\n".join(text),
        'type' : 'plain'

mn = reporters.MailNotifier(fromaddr="",

Another example of a function delivering a customized html email containing the last 80 log lines of logs of the last build step is given below:

from buildbot.plugins import util, reporters

import cgi, datetime

# FIXME: this code is barely readable, we should provide a better example with use of jinja templates
def html_message_formatter(mode, name, build, results, master_status):
    """Provide a customized message to Buildbot's MailNotifier.

    The last 80 lines of the log are provided as well as the changes
    relevant to the build.  Message content is formatted as html.
    result = util.Results[results]

    limit_lines = 80
    text = list()
    text.append(u'<h4>Build status: %s</h4>' % result.upper())
    text.append(u'<table cellspacing="10"><tr>')
    text.append(u"<td>Buildslave for this Build:</td><td><b>%s</b></td></tr>" % build.getSlavename())
    if master_status.getURLForThing(build):
        text.append(u'<tr><td>Complete logs for all build steps:</td><td><a href="%s">%s</a></td></tr>'
                    % (master_status.getURLForThing(build),
        text.append(u'<tr><td>Build Reason:</td><td>%s</td></tr>' % build.getReason())
        source = u""
        for ss in build.getSourceStamps():
            if ss.codebase:
                source += u'%s: ' % ss.codebase
            if ss.branch:
                source += u"[branch %s] " % ss.branch
            if ss.revision:
                source +=  ss.revision
                source += u"HEAD"
            if ss.patch:
                source += u" (plus patch)"
            if ss.patch_info: # add patch comment
                source += u" (%s)" % ss.patch_info[1]
        text.append(u"<tr><td>Build Source Stamp:</td><td><b>%s</b></td></tr>" % source)
        text.append(u"<tr><td>Blamelist:</td><td>%s</td></tr>" % ",".join(build.getResponsibleUsers()))
        if ss.changes:
            text.append(u'<h4>Recent Changes:</h4>')
            for c in ss.changes:
                cd = c.asDict()
                when = datetime.datetime.fromtimestamp(cd['when'] ).ctime()
                text.append(u'<table cellspacing="10">')
                text.append(u'<tr><td>Repository:</td><td>%s</td></tr>' % cd['repository'] )
                text.append(u'<tr><td>Project:</td><td>%s</td></tr>' % cd['project'] )
                text.append(u'<tr><td>Time:</td><td>%s</td></tr>' % when)
                text.append(u'<tr><td>Changed by:</td><td>%s</td></tr>' % cd['who'] )
                text.append(u'<tr><td>Comments:</td><td>%s</td></tr>' % cd['comments'] )
                files = cd['files']
                if files:
                    text.append(u'<table cellspacing="10"><tr><th align="left">Files</th></tr>')
                    for file in files:
                        text.append(u'<tr><td>%s:</td></tr>' % file['name'] )
        # get all the steps in build in reversed order
        rev_steps = reversed(build.getSteps())
        # find the last step that finished
        for step in rev_steps:
            if step.isFinished():
        # get logs for the last finished step
        if step.isFinished():
            logs = step.getLogs()
        # No step finished, loop just exhausted itself; so as a special case we fetch all logs
            logs = build.getLogs()
        # logs within a step are in reverse order. Search back until we find stdio
        for log in reversed(logs):
            if log.getName() == 'stdio':
        name = "%s.%s" % (log.getStep().getName(), log.getName())
        status, dummy = log.getStep().getResults()
        # XXX logs no longer have getText methods!!
        content = log.getText().splitlines() # Note: can be VERY LARGE
        url = u'%s/steps/%s/logs/%s' % (master_status.getURLForThing(build),

        text.append(u'<i>Detailed log of last build step:</i> <a href="%s">%s</a>'
                    % (url, url))
        text.append(u'<h4>Last %d lines of "%s"</h4>' % (limit_lines, name))
        unilist = list()
        for line in content[len(content)-limit_lines:]:
        text.append(u'<b>-The Buildbot</b>')
        return {
            'body': u"\n".join(text),
            'type': 'html'

mn = reporters.MailNotifier(fromaddr="",

MailNotifier arguments

The email address to be used in the 'From' header.
(boolean). If True (the default), send mail to all of the Interested Users. If False, only send mail to the extraRecipients list.
(list of strings). A list of email addresses to which messages should be sent (in addition to the InterestedUsers list, which includes any developers who made Changes that went into this build). It is a good idea to create a small mailing list and deliver to that, then let subscribers come and go as they please.
(string). A string to be used as the subject line of the message. %(builder)s will be replaced with the name of the builder which provoked the message.

Mode is a list of strings; however there are two strings which can be used as shortcuts instead of the full lists. The possible shortcuts are:

Always send mail about builds. Equivalent to (change, failing, passing, problem, warnings, exception).
Equivalent to (warnings, failing).

(list of strings). A combination of:

Send mail about builds which change status.
Send mail about builds which fail.
Send mail about builds which succeed.
Send mail about a build which failed when the previous build has passed.
Send mail about builds which generate warnings.
Send mail about builds which generate exceptions.

Defaults to (failing, passing, warnings).

(list of strings). A list of builder names for which mail should be sent. Defaults to None (send mail for all builds). Use either builders or tags, but not both.
(list of strings). A list of tag names to serve status information for. Defaults to None (all tags). Use either builders or tags, but not both.
(boolean). If True, include all build logs as attachments to the messages. These can be quite large. This can also be set to a list of log names, to send a subset of the logs. Defaults to False.
(boolean). If True, include the patch content if a patch was present. Patches are usually used on a Try server. Defaults to True.
(boolean). If True, send a single summary email consisting of the concatenation of all build completion messages rather than a completion message for each build. Defaults to False.
(string). The host to which the outbound SMTP connection should be made. Defaults to 'localhost'
(int). The port that will be used on outbound SMTP connections. Defaults to 25.
(boolean). When this argument is True (default is False) MailNotifier sends emails using TLS and authenticates with the relayhost. When using TLS the arguments smtpUser and smtpPassword must also be specified.
(string). The user name to use when authenticating with the relayhost.
(string). The password that will be used when authenticating with the relayhost.

(implementor of IEmailLookup). Object which provides IEmailLookup, which is responsible for mapping User names (which come from the VC system) into valid email addresses.

If the argument is not provided, the MailNotifier will attempt to build the sendToInterestedUsers from the authors of the Changes that led to the Build via User Objects. If the author of one of the Build's Changes has an email address stored, it will added to the recipients list. With this method, owners are still added to the recipients. Note that, in the current implementation of user objects, email addresses are not stored; as a result, unless you have specifically added email addresses to the user database, this functionality is unlikely to actually send any emails.

Most of the time you can use a simple Domain instance. As a shortcut, you can pass as string: this will be treated as if you had provided Domain(str). For example, lookup='' will allow mail to be sent to all developers whose SVN usernames match their account names. See buildbot/reporters/ for more details.

Regardless of the setting of lookup, MailNotifier will also send mail to addresses in the extraRecipients list.

This is a optional function that can be used to generate a custom mail message. A messageFormatter function takes the mail mode (mode), builder name (name), the build data api results (build), the result code (results), and a reference to the BuildMaster object (master), which can then be used to create additional data api calls. It returns a dictionary. The body key gives a string that is the complete text of the message. The type key is the message type ('plain' or 'html'). The 'html' type should be used when generating an HTML message. The subject key is optional, but gives the subject for the email.
(dictionary). A dictionary containing key/value pairs of extra headers to add to sent e-mails. Both the keys and the values may be a Interpolate instance.

As a help to those writing messageFormatter functions, the following table describes how to get some useful pieces of information from the various data objects:

Name of the builder that generated this event
Title of the buildmaster
MailNotifier mode
mode (a combination of change, failing, passing, problem, warnings, exception, all)

Builder result as a string

from buildbot.plugins import util
result_str = util.Results[results]
# one of 'success', 'warnings', 'failure', 'skipped', or 'exception'
URL to build page
reporters.utils.getURLForBuild(master, build['buildid'])
URL to buildbot main page
Build text
Mapping of property names to (values, source)
Slave name
Build reason (from a forced build)
List of responsible users
reporters.utils.getResponsibleUsersForBuild(master, build['buildid'])


class buildbot.status.words.IRC

The IRC status target creates an IRC bot which will attach to certain channels and be available for status queries. It can also be asked to announce builds as they occur, or be told to shut up.

from buildbot.plugins import status
irc = status.IRC("", "botnickname",
                 channels=[{"channel": "#example1"},
                           {"channel": "#example2",
                            "password": "somesecretpassword"}],
                   'exception': 1,
                   'successToFailure': 1,
                   'failureToSuccess': 1,

The following parameters are accepted by this class:

(mandatory) The IRC server adress to connect to.
(mandatory) The name this bot will use on the IRC server.
(mandatory) This is a list of channels to join on the IRC server. Each channel can be a string (e.g. #buildbot), or a dictionnary {'channel': '#buildbot', 'password': 'secret'} if each channel requires a different password. A global password can be set with the password parameter.
(optional) This is a list of person to contact on the IRC server.
(optional, default to 6667) The port to connect to on the IRC server.
(optional, disabled by default) This allow user to force builds via this bot.
(optional) When set, this bot will only communicate about builders containing those tags.
(optional) The global password used to register the bot to the IRC server. If provided, it will be sent to Nickserv to claim the nickname: some IRC servers will not allow clients to send private messages until they have logged in with a password.
(optional) A dictionnary of events to be notified on the IRC channels. This parameter can be changed during run-time by sending the notify command to the bot.
(optional, disabled by default) Whether or not to display the blamelist for failed builds.
(optional, disabled by default) Whether or not to display the revision leading to the build the messages are about.
(optional, disabled by default) Whether or not to use SSL when connecting to the IRC server. Note that this option requires PyOpenSSL.
(optional) Delay to wait before reconnecting to the server when the connection has been lost.
(optional) Delay to wait before reconnecting to the IRC server when the connection failed.
(optional, enabled by default) The bot can add color to some of its messages. You might turn it off by setting this parameter to False.
(optional, disabled by default) This allow users to shutdown the master.

To use the service, you address messages at the buildbot, either normally (botnickname: status) or with private messages (/msg botnickname status). The buildbot will respond in kind.

If you issue a command that is currently not available, the buildbot will respond with an error message. If the noticeOnChannel=True option was used, error messages will be sent as channel notices instead of messaging.

Some of the commands currently available:

list builders
Emit a list of all configured builders
status BUILDER
Announce the status of a specific Builder: what it is doing right now.
status all
Announce the status of all Builders
If the given Builder is currently running, wait until the Build is finished and then announce the results.
Return the results of the last build to run on the given Builder.
Join the given IRC channel
Leave the given IRC channel
notify on|off|list EVENT

Report events relating to builds. If the command is issued as a private message, then the report will be sent back as a private message to the user who issued the command. Otherwise, the report will be sent to the channel. Available events to be notified are:

A build has started
A build has finished
A build finished successfully
A build failed
A build generated and exception
The previous build was x, but this one is Y, where x and Y are each one of success, warnings, failure, exception (except Y is capitalized). For example: successToFailure will notify if the previous build was successful, but this one failed
Describe a command. Use help commands to get a list of known commands.
shutdown ARG

Control the shutdown process of the buildbot master. Available arguments are:

Check if the buildbot master is running or shutting down
Start clean shutdown
Stop clean shutdown
Shutdown immediately without waiting for the builders to finish
Announce the URL of the Buildbot's home page.
Announce the version of this Buildbot.

Additionally, the config file may specify default notification options as shown in the example earlier.

If the allowForce=True option was used, some additional commands will be available:

force build [--branch=BRANCH] [--revision=REVISION] [--props=PROP1=VAL1,PROP2=VAL2...] BUILDER REASON
Tell the given Builder to start a build of the latest code. The user requesting the build and REASON are recorded in the Build status. The buildbot will announce the build's status when it finishes.The user can specify a branch and/or revision with the optional parameters --branch=BRANCH and --revision=REVISION. The user can also give a list of properties with --props=PROP1=VAL1,PROP2=VAL2...
Terminate any running build in the given Builder. REASON will be added to the build status to explain why it was stopped. You might use this if you committed a bug, corrected it right away, and don't want to wait for the first build (which is destined to fail) to complete before starting the second (hopefully fixed) build.

If the tags is set (see the tags option in Builder Configuration) changes related to only builders belonging to those tags of builders will be sent to the channel.

If the useRevisions option is set to True, the IRC bot will send status messages that replace the build number with a list of revisions that are contained in that build. So instead of seeing build #253 of ..., you would see something like build containing revisions [a87b2c4]. Revisions that are stored as hashes are shortened to 7 characters in length, as multiple revisions can be contained in one build and may exceed the IRC message length limit.

Two additional arguments can be set to control how fast the IRC bot tries to reconnect when it encounters connection issues. lostDelay is the number of of seconds the bot will wait to reconnect when the connection is lost, where as failedDelay is the number of seconds until the bot tries to reconnect when the connection failed. lostDelay defaults to a random number between 1 and 5, while failedDelay defaults to a random one between 45 and 60. Setting random defaults like this means multiple IRC bots are less likely to deny each other by flooding the server.


class buildbot.status.status_push.StatusPush
def Process(self):
    print str(self.queue.popChunk())

from buildbot.plugins import status
sp = status.StatusPush(serverPushCb=Process, bufferDelay=0.5, retryDelay=5)

StatusPush batches events normally processed and sends it to the serverPushCb callback every bufferDelay seconds. The callback should pop items from the queue and then queue the next callback. If no items were popped from self.queue, retryDelay seconds will be waited instead.


from buildbot.plugins import status
sp = status.HttpStatusPush(serverUrl="")

HttpStatusPush builds on StatusPush and sends HTTP requests to serverUrl, with all the items json-encoded. It is useful to create a status front end outside of buildbot for better scalability.


class buildbot.status.status_gerrit.GerritStatusPush

GerritStatusPush sends review of the Change back to the Gerrit server, optionally also sending a message when a build is started. GerritStatusPush can send a separate review for each build that completes, or a single review summarizing the results for all of the builds.

class GerritStatusPush(server, username, reviewCB, startCB, port, reviewArg, startArg, summaryCB, summaryArg, identity_file, ...)
  • server (string) -- Gerrit SSH server's address to use for push event notifications.
  • username (string) -- Gerrit SSH server's username.
  • identity_file -- (optional) Gerrit SSH identity file.
  • port (int) -- (optional) Gerrit SSH server's port (default: 29418)
  • reviewCB -- (optional) callback that is called each time a build is finished, and that is used to define the message and review approvals depending on the build result.
  • reviewArg --

    (optional) argument passed to the review callback.

    If reviewCB callback is specified, it determines the message and score to give when sending a review for each separate build. It should return a dictionary:

    {'message': message,
     'labels': {label-name: label-score,

    For example:

    def gerritReviewCB(builderName, build, result, status, arg):
        if result == util.RETRY:
            return dict()
        message =  "Buildbot finished compiling your patchset\n"
        message += "on configuration: %s\n" % builderName
        message += "The result is: %s\n" % util.Results[result].upper()
        if arg:
            message += "\nFor more details visit:\n"
            message += status.getURLForThing(build) + "\n"
        if result == util.SUCCESS:
            verified = 1
            verified = -1
        return dict(message=message, labels={'Verified': verified})

    Which require an extra import in the config:

    from buildbot.plugins import util
  • startCB -- (optional) callback that is called each time a build is started. Used to define the message sent to Gerrit.
  • startArg --

    (optional) argument passed to the start callback.

    If startCB is specified, it should return a message. This message will be sent to the Gerrit server when each build is started, for example:

    def gerritStartCB(builderName, build, arg):
        print "gerritStartCB..."
        message = "Buildbot started compiling your patchset\n"
        message += "on configuration: %s\n" % builderName
        return message
  • summaryCB -- (optional) callback that is called each time a buildset finishes, and that is used to define a message and review approvals depending on the build result.
  • summaryArg --

    (optional) argument passed to the summary callback.

    If summaryCB callback is specified, determines the message and score to give when sending a single review summarizing all of the builds. It should return a dictionary:

    {'message': message,
     'labels': {label-name: label-score,
    def gerritSummaryCB(buildInfoList, results, status, arg):
        success = False
        failure = False
        msgs = []
        for buildInfo in buildInfoList:
            msg = "Builder %(name)s %(resultText)s (%(text)s)" % buildInfo
            link = buildInfo.get('url', None)
            if link:
                msg += " - " + link
                msg += "."
            if buildInfo['result'] == util.SUCCESS:
                success = True
                failure = True
        if success and not failure:
            verified = 1
            verified = -1
        return dict(message='\n\n'.join(msgs),
                        'Verified': verified


By default, a single summary review is sent; that is, a default summaryCB is provided, but no reviewCB or startCB.


If reviewCB or summaryCB do not return any labels, only a message will be pushed to the Gerrit server.

See also

master/docs/examples/git_gerrit.cfg and master/docs/examples/repo_gerrit.cfg in the Buildbot distribution provide a full example setup of Git+Gerrit or Repo+Gerrit of GerritStatusPush.


class buildbot.status.github.GitHubStatus
from buildbot.plugins import status, util

repoOwner = Interpolate("%(prop:github_repo_owner)s")
repoName = Interpolate("%(prop:github_repo_name)s")
sha = Interpolate("%(src::revision)s")
gs = status.GitHubStatus(token='githubAPIToken',
                         startDescription='Build started.',
                         endDescription='Build done.')
buildbot_bbtools = util.BuilderConfig(
        "github_repo_owner": "buildbot",
        "github_repo_name": "bbtools",

GitHubStatus publishes a build status using GitHub Status API.

It requires txgithub <> package to allow interaction with GitHub API.

It is configured with at least a GitHub API token, repoOwner and repoName arguments.

You can create a token from you own GitHub - Profile - Applications - Register new application or use an external tool to generate one.

repoOwner, repoName are used to inform the plugin where to send status for build. This allow using a single GitHubStatus for multiple projects. repoOwner, repoName can be passes as a static string (for single project) or Interpolate for dynamic substitution in multiple project.

sha argument is use to define the commit SHA for which to send the status. By default sha is defined as: %(src::revision)s.

In case any of repoOwner, repoName or sha returns None, False or empty string, the plugin will skip sending the status.

You can define custom start and end build messages using the startDescription and endDescription optional interpolation arguments.

Starting with Buildbot version 0.8.11, GitHubStatus supports additional parameter -- baseURL -- that allows to specify a different API base endpoint. This is required if you work with GitHub Enterprise installation. This feature requires txgithub of version 0.2.0 or better.


class buildbot.status.status_stash.StashStatusPush
from buildbot.plugins import status

ss = status.StashStatusPush('',

StashStatusPush publishes build status using Stash Build Integration REST API. The build status is published to a specific commit SHA in Stash. It tracks the last build for each builderName for each commit built.

Specifically, it follows the Updating build status for commits document.

It uses the standard Python Twisted Agent to make REST requests to the stash server. It uses HTTP Basic AUTH. As a result, we recommend you use https in your base_url rather than http. If you use https, it requires pyOpenSSL.

Configuration requires exactly 3 parameters:

the base url of the stash host, up to and optionally including the first / of the path.
the stash user to post as
the stash user's password