Re: [Monotone-devel] Help request with buildbot for monotone

[Richard Levitte]

In message <address@hidden> on Mon, 09 Jul 2007 14:15:18 +0200, Markus 
Schiltknecht <address@hidden> said:

markus> I'm unclear on why your slave fails to print the 'message from
markus> master: attached'.  Can you simply try restarting the slave?
markus> What does the slave's .tac file look like? What does your
markus> master.cfg's c['bots'] look like?

It's possible that I restarted the master only at some point without
restarting the slave.  I'm not sure if that's relevant.

Anyway, I just restarted the slave, and this is the fresh log since
then:

   2007/07/09 14:36 +0200 [-] Log opened.
   2007/07/09 14:36 +0200 [-] twistd 2.5.0 (/usr/bin/python 2.4.4) starting up
   2007/07/09 14:36 +0200 [-] reactor class: <class 
'twisted.internet.selectreactor.SelectReactor'>
   2007/07/09 14:36 +0200 [-] Loading buildbot.tac...
   2007/07/09 14:36 +0200 [-] Creating BuildSlave
   2007/07/09 14:36 +0200 [-] Loaded.
   2007/07/09 14:36 +0200 [-] Starting factory <buildbot.slave.bot.BotFactory 
instance at 0xb76f62ac>
   2007/07/09 14:36 +0200 [Broker,client] message from master: attached
   2007/07/09 14:36 +0200 [Broker,client] I have a leftover directory 'info' 
that is not being used by the buildmaster: you can delete it now
   2007/07/09 14:36 +0200 [Broker,client] 
SlaveBuilder.remote_print(i386-debian-testing): message from master: attached
   2007/07/09 14:36 +0200 [Broker,client] sending application-level keepalives 
every 600 seconds
   2007/07/09 14:36 +0200 [Broker,client] 
SlaveBuilder.remote_print(i386-debian-testing): message from master: ping
   2007/07/09 14:36 +0200 [Broker,client] 
SlaveBuilder.remote_ping(<SlaveBuilder 'i386-debian-testing' at -1217984756>)
   2007/07/09 14:36 +0200 [Broker,client] <SlaveBuilder 'i386-debian-testing' 
at -1217984756>.startBuild

I'm attaching the slave's buildbot.tac and the master's master.cfg
(with the bot password cleared after having verified that it's spelled
the same in both files;-)).

markus> What version of buildbot are you using? I'm on CVS HEAD, but
markus> debian testing seems quite up to date with 0.7.5 as well,
markus> while debian stable uses 0.7.4, AFAICT.

address@hidden:~/wrk$ apt-show-versions buildbot
buildbot/testing uptodate 0.7.5-1.1

from twisted.application import service
from buildbot.slave.bot import BuildSlave

basedir = r'/var/lib/monotone/buildslave'
host = 'localhost'
port = 9001
slavename = 'i386-debian-testing'
passwd = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
keepalive = 600
usepty = 1
umask = None

application = service.Application('buildslave')
s = BuildSlave(host, port, slavename, passwd, basedir, keepalive, usepty,
               umask=umask)
s.setServiceParent(application)

# -*- python -*-
# 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 .


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

####### BUILDSLAVES

# the 'bots' list defines the set of allowable buildslaves. Each element is a
# tuple of bot-name and bot-password. These correspond to values given to the
# buildslave's mktap invocation.
c['bots'] = [("i386-debian-testing", "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX")]


# 'slavePortnum' defines the TCP port to listen on. This must match the value
# configured into the buildslaves (with their --master option)

c['slavePortnum'] = 9001


####### CHANGESOURCES

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

c['sources'] = []

# For example, if you had CVSToys installed on your repository, and your
# CVSROOT/freshcfg file had an entry like this:
#pb = ConfigurationSet([
#    (None, None, None, PBService(userpass=('foo', 'bar'), port=4519)),
#    ])

# then you could use the following buildmaster Change Source to subscribe to
# the FreshCVS daemon and be notified on every commit:
#
#from buildbot.changes.freshcvs import FreshCVSSource
#fc_source = FreshCVSSource("cvs.example.com", 4519, "foo", "bar")
#c['sources'].append(fc_source)

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

#from buildbot.changes.monotone import MonotoneSource
#c['sources'].append(MonotoneSource(server_addr="monotone.ca",
#                                  branch="net.venge.monotone",
#                                  monotone_exec="mtn"))


####### SCHEDULERS

## configure the Schedulers

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


####### 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 bilder
#  slavename (required): which slave to use, must appear in c['bots']
#  builddir (required): which subdirectory to run the builder in
#  factory (required): a BuildFactory to define how the build is run
#  periodicBuildTime (optional): if set, force a build every N seconds

# 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/process/step.py for
# CVS, SVN, and others.

#cvsroot = ":pserver:address@hidden:/cvsroot/buildbot"
#cvsmodule = "buildbot"

builders = []

from buildbot.process import factory
from buildbot.steps.source import Monotone
from buildbot.steps.shell import ShellCommand
from buildbot.steps.shell import Configure
from buildbot.steps.shell import Compile
from buildbot.steps.shell import Test
#f1 = factory.BuildFactory()
#f1.addStep(CVS,
#           cvsroot=cvsroot, cvsmodule=cvsmodule, login="",
#           mode="copy")
#f1.addStep(Compile, command=["./setup.py", "build"])
#f1.addStep(Trial, testpath=".")

f_unix_general = factory.BuildFactory()
f_unix_general.addStep(Monotone,
                       server_addr="monotone.ca", branch="net.venge.monotone",
                       monotone="mtn")
f_unix_general.addStep(ShellCommand, command=["autoreconf", "-i"])
f_unix_general.addStep(Configure)
f_unix_general.addStep(Compile)
f_unix_general.addStep(Test, command=["make", "check"])

b_i386_debian_testing = {'name': "i386-debian-testing",
                         'slavename': "i386-debian-testing",
                         'builddir': "full",
                         'factory': f_unix_general,
                        }
c['builders'] = [b_i386_debian_testing]


####### STATUS TARGETS

# 'status' is a list of Status Targets. The results of each build will be
# pushed to these targets. buildbot/status/*.py has a variety to choose from,
# including web pages, email senders, and IRC bots.

c['status'] = []

from buildbot.status import html
c['status'].append(html.Waterfall(http_port=8010))

# from buildbot.status import mail
# c['status'].append(mail.MailNotifier(fromaddr="address@hidden",
#                                      extraRecipients=["address@hidden"],
#                                      sendToInterestedUsers=False))
#
# from buildbot.status import words
# c['status'].append(words.IRC(host="irc.example.com", nick="bb",
#                              channels=["#example"]))
#
# 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 commiting 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'] = "Monotone"
c['projectURL'] = "http://monotone.ca/";

# the 'buildbotURL' string should point to the location where the buildbot's
# internal web server (usually the html.Waterfall page) is visible. This
# typically uses the port number set in the Waterfall 'status' entry, but
# with an externally-visible host name which the buildbot cannot figure out
# without some help.

c['buildbotURL'] = "http://monotone.ca:8010/";