Skip to content

Commit

Permalink
better setup docs, example config
Browse files Browse the repository at this point in the history
  • Loading branch information
@djmitche
djmitche committed Dec 16, 2010
1 parent 9d491c2 commit 85eb1b0
Show file tree
Hide file tree
Showing 2 changed files with 61 additions and 145 deletions.
170 changes: 47 additions & 123 deletions master/buildbot/scripts/sample.cfg
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,118 +2,69 @@
# ex: set syntax=python:

# This is a sample buildmaster config file. It must be installed as
# 'master.cfg' in your buildmaster's base directory (although the filename
# can be changed with the --basedir option to 'mktap buildbot master').

# It has one job: define a dictionary named BuildmasterConfig. This
# dictionary has a variety of keys to control different aspects of the
# buildmaster. They are documented in docs/config.xhtml .

# 'master.cfg' in your buildmaster's base directory.

# This is the dictionary that the buildmaster pays attention to. We also use
# a shorter alias to save typing.
c = BuildmasterConfig = {}

####### DB URL

# This specifies what database buildbot uses to store change and scheduler
# state
c['db_url'] = "sqlite:///state.sqlite"

####### BUILDSLAVES

# the 'slaves' list defines the set of allowable buildslaves. Each element is
# a BuildSlave object, which is created with bot-name, bot-password. These
# correspond to values given to the buildslave's mktap invocation.
# The 'slaves' list defines the set of recognized buildslaves. Each element is
# a BuildSlave object, specifying a username and password. The same username and
# password must be configured on the slave.
from buildbot.buildslave import BuildSlave
c['slaves'] = [BuildSlave("bot1name", "bot1passwd")]

# to limit to two concurrent builds on a slave, use
# c['slaves'] = [BuildSlave("bot1name", "bot1passwd", max_builds=2)]


# 'slavePortnum' defines the TCP port to listen on. This must match the value
# configured into the buildslaves (with their --master option)
c['slaves'] = [BuildSlave("example-slave", "pass")]

# 'slavePortnum' defines the TCP port to listen on for connections from slaves.
# This must match the value configured into the buildslaves (with their
# --master option)
c['slavePortnum'] = 9989

####### CHANGESOURCES

# the 'change_source' setting tells the buildmaster how it should find out
# about source code changes. Any class which implements IChangeSource can be
# put here: there are several in buildbot/changes/*.py to choose from.

from buildbot.changes.pb import PBChangeSource
c['change_source'] = PBChangeSource()

# or, use a PBChangeSource, and then have your repository's commit script run
# 'buildbot sendchange', or use contrib/svn_buildbot.py, or
# contrib/arch_buildbot.py :
#
#from buildbot.changes.pb import PBChangeSource
#c['change_source'] = PBChangeSource()

# If you wat to use SVNPoller, it might look something like
# # Where to get source code changes
# from buildbot.changes.svnpoller import SVNPoller
# source_code_svn_url='https://svn.myproject.org/bluejay/trunk'
# svn_poller = SVNPoller(
# svnurl=source_code_svn_url,
# pollinterval=60*60, # seconds
# histmax=10,
# svnbin='/usr/bin/svn',
## )
# c['change_source'] = [ svn_poller ]
# about source code changes. Here we point to the buildbot clone of pyflakes.

from buildbot.changes.gitpoller import GitPoller
c['change_source'] = GitPoller(
'git://github.com/buildbot/pyflakes.git',
branch='master', pollinterval=1200)

####### SCHEDULERS

## configure the Schedulers
# Configure the Schedulers, which decide how to react to incoming changes. In this
# case, just kick off a 'runtests' build

from buildbot.scheduler import Scheduler
c['schedulers'] = []
c['schedulers'].append(Scheduler(name="all", branch=None,
treeStableTimer=2*60,
builderNames=["buildbot-full"]))

treeStableTimer=None,
builderNames=["runtests"]))

####### BUILDERS

# the 'builders' list defines the Builders. Each one is configured with a
# dictionary, using the following keys:
# name (required): the name used to describe this builder
# slavename or slavenames (required): which slave(s) to use (must appear in c['slaves'])
# factory (required): a BuildFactory to define how the build is run
# builddir (optional): which subdirectory to run the builder in

# buildbot/process/factory.py provides several BuildFactory classes you can
# start with, which implement build processes for common targets (GNU
# autoconf projects, CPAN perl modules, etc). The factory.BuildFactory is the
# base class, and is configured with a series of BuildSteps. When the build
# is run, the appropriate buildslave is told to execute each Step in turn.

# the first BuildStep is typically responsible for obtaining a copy of the
# sources. There are source-obtaining Steps in buildbot/steps/source.py for
# CVS, SVN, and others.

cvsroot = ":pserver:anonymous@cvs.sourceforge.net:/cvsroot/buildbot"
cvsmodule = "buildbot"

from buildbot.process import factory
from buildbot.steps.source import CVS
from buildbot.steps.shell import Compile
from buildbot.steps.python_twisted import Trial
f1 = factory.BuildFactory()
f1.addStep(CVS(cvsroot=cvsroot, cvsmodule=cvsmodule, login="", mode="copy"))
f1.addStep(Compile(command=["python", "./setup.py", "build"]))
f1.addStep(Trial(testChanges=True, testpath="."))
# The 'builders' list defines the Builders, which tell Buildbot how to perform a build:
# what steps, and which slaves can execute them. Note that any particular build will
# only take place on one slave.

from buildbot.process.factory import BuildFactory
from buildbot.steps.source import Git
from buildbot.steps.shell import ShellCommand

factory = BuildFactory()
# check out the source
factory.addStep(Git(repourl='git://github.com/buildbot/pyflakes.git', mode='copy'))
# run the tests (note that this will require that 'trial' is installed)
factory.addStep(ShellCommand(command=["trial", "pyflakes"]))

from buildbot.config import BuilderConfig
b1 = BuilderConfig(name="buildbot-full",
slavename="bot1name",
builddir="full",
factory=f1)
c['builders'] = [b1]

c['builders'] = []
c['builders'].append(
BuilderConfig(name="runtests",
slavenames=["example-slave"],
factory=factory))

####### STATUS TARGETS

Expand All @@ -129,7 +80,7 @@ authz_cfg=authz.Authz(
# change any of these to True to enable; see the manual for more
# options
gracefulShutdown = False,
forceBuild = False,
forceBuild = True, # use this to test your slave once it is set up
forceAllBuilds = False,
pingBuilder = False,
stopBuild = False,
Expand All @@ -138,50 +89,15 @@ authz_cfg=authz.Authz(
)
c['status'].append(html.WebStatus(http_port=8010, authz=authz_cfg))

# from buildbot.status import mail
# c['status'].append(mail.MailNotifier(fromaddr="buildbot@localhost",
# extraRecipients=["builds@example.com"],
# sendToInterestedUsers=False))
#
# from buildbot.status import words
# c['status'].append(words.IRC(host="irc.example.com", nick="bb",
# channels=["#example"]))
# c['status'].append(words.IRC(host="irc.example.com", nick="bb",
# channels=["#example"], useSSL=True))
#
# from buildbot.status import client
# c['status'].append(client.PBListener(9988))


####### DEBUGGING OPTIONS

# if you set 'debugPassword', then you can connect to the buildmaster with
# the diagnostic tool in contrib/debugclient.py . From this tool, you can
# manually force builds and inject changes, which may be useful for testing
# your buildmaster without actually committing changes to your repository (or
# before you have a functioning 'sources' set up). The debug tool uses the
# same port number as the slaves do: 'slavePortnum'.

#c['debugPassword'] = "debugpassword"

# if you set 'manhole', you can ssh into the buildmaster and get an
# interactive python shell, which may be useful for debugging buildbot
# internals. It is probably only useful for buildbot developers. You can also
# use an authorized_keys file, or plain telnet.
#from buildbot import manhole
#c['manhole'] = manhole.PasswordManhole("tcp:9999:interface=127.0.0.1",
# "admin", "password")


####### PROJECT IDENTITY

# the 'projectName' string will be used to describe the project that this
# buildbot is working on. For example, it is used as the title of the
# waterfall HTML page. The 'projectURL' string will be used to provide a link
# from buildbot HTML pages to your project's home page.

c['projectName'] = "Buildbot"
c['projectURL'] = "http://buildbot.net/"
c['projectName'] = "Pyflakes"
c['projectURL'] = "http://divmod.org/trac/wiki/DivmodPyflakes"

# the 'buildbotURL' string should point to the location where the buildbot's
# internal web server (usually the html.WebStatus page) is visible. This
Expand All @@ -190,3 +106,11 @@ c['projectURL'] = "http://buildbot.net/"
# without some help.

c['buildbotURL'] = "http://localhost:8010/"

####### DB URL

# This specifies what database buildbot uses to store change and scheduler
# state. You can leave this at its default for all but the largest
# installations.
c['db_url'] = "sqlite:///state.sqlite"

36 changes: 14 additions & 22 deletions master/docs/installation.texinfo
View file
Original file line number Diff line number Diff line change
Expand Up @@ -152,7 +152,8 @@ PYTHONPATH=. trial buildslave.test

Nothing should fail, a few might be skipped. If any of the tests fail, you
should stop and investigate the cause before continuing the installation
process, as it will probably be easier to track down the bug early.
process, as it will probably be easier to track down the bug early. This may
be a good time to contact the Buildbot developers for help.

If you cannot or do not wish to install the buildbot into a site-wide
location like @file{/usr} or @file{/usr/local}, you can also install
Expand All @@ -164,27 +165,18 @@ it into the account's home directory or any other location using a tool like @ur
As you learned earlier (@pxref{System Architecture}), the buildmaster
runs on a central host (usually one that is publically visible, so
everybody can check on the status of the project), and controls all
aspects of the buildbot system. Let us call this host
@code{buildbot.example.org}.

You may wish to create a separate user account for the buildmaster,
perhaps named @code{buildmaster}. This can help keep your personal
configuration distinct from that of the buildmaster and is useful if
you have to use a mail-based notification system (@pxref{Change
Sources}). However, the Buildbot will work just fine with your regular
user account.

You need to choose a directory for the buildmaster, called the
@code{basedir}. This directory will be owned by the buildmaster, which
will use configuration files therein, and create status files as it
runs. @file{~/Buildbot} is a likely value. If you run multiple
buildmasters in the same account, or if you run both masters and
slaves, you may want a more distinctive name like
@file{~/Buildbot/master/gnomovision} or
@file{~/Buildmasters/fooproject}. If you are using a separate user
account, this might just be @file{~buildmaster/masters/fooproject}.

Once you've picked a directory, use the @command{buildbot
aspects of the buildbot system.

You will probably wish to create a separate user account for the buildmaster,
perhaps named @code{buildmaster}. Do not run the buildmaster as root!

You also need to choose a directory for the buildmaster, called the
@code{basedir}. This directory will be owned by the buildmaster. It will
contain configuration, the adtabase, and status information - including
logfiles. On a large buildmaster this directory will see a lot of activity, so
it should be on a disk with adequate space and speed.

Once you've picked a basedir, use the @command{buildbot
create-master} command to create the directory and populate it with
startup files:

Expand Down

0 comments on commit 85eb1b0

Please sign in to comment.