Navigation

This tutorial will expand on the First Run tutorial by taking a quick tour around some of the features of buildbot that are hinted at in the comments in the sample configuration.
We will simply change parts of the default configuration and explain the activated features.

As a part of this tutorial, we will make buildbot do a few actual builds.

####### PROJECT IDENTITY# the 'title' string will appear at the top of this buildbot installation's# home pages (linked to the 'titleURL').c['title']="Pyflakes"c['titleURL']="http://divmod.org/trac/wiki/DivmodPyflakes"

If you want, you can change either of these links to anything you want to see what happens when you change them.

After making a change go into the terminal and type:

buildbot reconfig master

You will see a handful of lines of output from the master log, much like this:

The important lines are the ones telling you that it is loading the new configuration at the top, and the one at the bottom saying that the update is complete.

Now, if you go back to the waterfall page, you will see that the project's name is whatever you may have changed it to and when you click on the URL of the project name at the bottom of the page it should take you to the link you put in the configuration.

By now you're probably thinking: "All this time spent and still not done a single build? What was the name of this project again?"

On the waterfall page, click on the runtests link.
You'll see a builder page, and in the upper-right corner is a box where you can login.
The default username and password are both "pyflakes".
Once you've logged in, you will see some new options that allow you to force a build:

Click Force Build - there's no need to fill in any of the fields in this case.
Next, click on view in waterfall.

Buildbot includes an IRC bot that you can tell to join a channel and control to report on the status of buildbot.

First, start an IRC client of your choice, connect to irc.freenode.org and join an empty channel.
In this example we will use #buildbot-test, so go join that channel.
(Note: please do not join the main buildbot channel!)

Edit :file:'master.cfg' and look for the STATUS TARGETS section.
At the end of that section add the lines:

You should see the bot now joining in your IRC client.
In your IRC channel, type:

bbtest: commands

to get a list of the commands the bot supports.

Let's tell the bot to notify certain events, to learn which EVENTS we can notify on:

bbtest: help notify

Now let's set some event notifications:

bbtest: notify on started
bbtest: notify on finished
bbtest: notify on failure

The bot should have responded to each of the commands:

<@lsblakk> bbtest: notify on started
<bbtest> The following events are being notified: ['started']
<@lsblakk> bbtest: notify on finished
<bbtest> The following events are being notified: ['started', 'finished']
<@lsblakk> bbtest: notify on failure
<bbtest> The following events are being notified: ['started', 'failure', 'finished']

Now, go back to the web interface and force another build.

Notice how the bot tells you about the start and finish of this build:

c['status']=[]frombuildbot.statusimporthtmlfrombuildbot.status.webimportauthz,authauthz_cfg=authz.Authz(# change any of these to True to enable; see the manual for more# optionsauth=auth.BasicAuth([("pyflakes","pyflakes")]),gracefulShutdown=False,forceBuild='auth',# use this to test your worker once it is set upforceAllBuilds=False,pingBuilder=False,stopBuild=False,stopAllBuilds=False,cancelPendingBuild=False,)c['status'].append(html.WebStatus(http_port=8010,authz=authz_cfg))

The auth.BasicAuth() define authorized users and their passwords.
You can change these or add new ones.

You can do some debugging by using manhole, an interactive Python shell.
It exposes full access to the buildmaster's account (including the ability to modify and delete files), so it should not be enabled with a weak or easily guessable password.

To use this you will need to install an additional package or two to your virtualenv:

Buildbot includes a way for developers to submit patches for testing without committing them to the source code control system.
(This is really handy for projects that support several operating systems or architectures.)

This will do gitdiff for you and send the resulting patch to the server for build and test against the latest sources from Git.

Now go back to the waterfall page, click on the runtests link, and scroll down.
You should see that another build has been started with your change (and stdout for the tests should be chock-full of parse trees as a result).
The "Reason" for the job will be listed as "'try' job", and the blamelist will be empty.

To make yourself show up as the author of the change, use the --who=emailaddr option on buildbottry to pass your email address.

To make a description of the change show up, use the --properties=comment="thisisacomment" option on buildbottry.

To use ssh instead of a private username/password database, see Try_Jobdir.