-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathboost-master-master.cfg
321 lines (263 loc) · 12.3 KB
/
boost-master-master.cfg
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
# -*- 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 '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.
from buildbot.buildslave import BuildSlave
c['slaves'] = [BuildSlave("boost-slave", "boost-pwd", max_builds=2)]
# 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['slavePortnum'] = 10012
####### 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()
# 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['change_source'] = fc_source
# 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['sources'] = [ svn_poller ]
####### SCHEDULERS
## configure the Schedulers
from buildbot.scheduler import Scheduler, Nightly
c['schedulers'] = []
# unfortunately boost release/trunk is regularly broken, so let's not get spammed with it
#c['schedulers'].append(Nightly(name="boost-nightly",
# branch=None,
# builderNames=["boost-trunk-builder", "boost-release-builder"],
# hour=1,
# minute=30))
####### 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 (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/steps/source.py for
# CVS, SVN, and others.
#cvsroot = ":pserver:[email protected]:/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="."))
#
#b1 = {'name': "buildbot-full",
# 'slavename': "bot1name",
# 'builddir': "full",
# 'factory': f1,
# }
#c['builders'] = [b1]
from buildbot.steps import source, shell
from buildbot.process import factory
def createBoostBuildFactory(branch,instdir):
f = factory.BuildFactory()
# checkout
f.addStep(source.SVN(
mode='update',
svnurl='http://svn.boost.org/svn/boost/' + branch,
always_purge=True))
f.addStep(shell.ShellCommand(
name='bootstrap',
command=['./bootstrap.sh', '--prefix=/var/lib/buildbot/instdirs/'+instdir, '--without-libraries=python']))
# TODO configure toolset?
f.addStep(shell.ShellCommand(
name='bjam (release)',
command=['./bjam', '--layout=tagged', '--variant=release', '-d+2', '--threading=multi']))
f.addStep(shell.ShellCommand(
name='bjam (debug)',
command=['./bjam', '--layout=tagged', '--variant=debug', '-d+2', '--threading=multi']))
f.addStep(shell.ShellCommand(
name='clean away libs',
command=['sh', '-c', 'rm -f /var/lib/buildbot/instdirs/'+instdir+'/lib/lib*.so*']))
f.addStep(shell.ShellCommand(
name='bjam install (release)',
command=['./bjam', '--layout=tagged', '--variant=release', '-d+2', '--threading=multi', 'install']))
f.addStep(shell.ShellCommand(
name='bjam install (debug)',
command=['./bjam', '--layout=tagged', '--variant=debug', '-d+2', '--threading=multi', 'install']))
return f
b_boost_trunk = {
'name': 'boost-trunk-builder',
'slavename': 'boost-slave',
'builddir': 'trunk',
'factory': createBoostBuildFactory('trunk/', 'boost-trunk/')
}
b_boost_release = {
'name': 'boost-release-builder',
'slavename': 'boost-slave',
'builddir': 'release',
'factory': createBoostBuildFactory('branches/release/', 'boost-release/')
}
c['builders'] = [b_boost_trunk, b_boost_release]
for version in [42,43,44,45,46,47,48,49,50,51,52,53,54,55]:
minor = 0
if version == 46:
minor = 1
buildername = 'boost-1.%d.%d-builder' % (version,minor)
branchname = 'tags/release/Boost_1_%d_%d' % (version,minor)
builddir = 'boost-1.%d.%d' % (version,minor)
instdir = 'boost-1_%d' % (version,)
c['builders'].append({
'name': buildername,
'slavename': 'boost-slave',
'builddir': builddir,
'factory': createBoostBuildFactory(branchname, instdir)
})
####### 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.WebStatus(http_port=8012,allowForce=True))
from buildbot.status import mail
c['status'].append(mail.MailNotifier(fromaddr="[email protected]",
extraRecipients=["[email protected]"],
sendToInterestedUsers=False,
relayhost="wagner.kr.tuwien.ac.at",
)
)
# from buildbot.status import mail
# c['status'].append(mail.MailNotifier(fromaddr="buildbot@localhost",
# extraRecipients=["[email protected]"],
# 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 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'] = "boost"
c['projectURL'] = "http://www.boost.org/"
# 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://gluck.kr.tuwien.ac.at:8012/"
# Horizons
#
# Buildbot stores historical information on disk in the form of "Pickle" files
# and compressed logfiles. In a large installation, these can quickly consume
# disk space, yet in many cases developers never consult this historical
# information.
#
# The changeHorizon key determines how many changes the master will keep a
# record of. One place these changes are displayed is on the waterfall page. This
# parameter defaults to 0, which means keep all changes indefinitely.
#
# The buildHorizon specifies the minimum number of builds for each builder which
# should be kept on disk. The eventHorizon specifies the minimum number of events
# to keep--events mostly describe connections and disconnections of slaves, and
# are seldom helpful to developers. The logHorizon gives the minimum number of
# builds for which logs should be maintained; this parameter must be less than or
# equal to buildHorizon. Builds older than logHorizon but not older than
# buildHorizon will maintain their overall status and the status of each step,
# but the logfiles will be deleted.
c['changeHorizon'] = 200
c['buildHorizon'] = 100
c['eventHorizon'] = 50
c['logHorizon'] = 40
c['buildCacheSize'] = 15
# Log Handling
#
# The logCompressionLimit enables compression of build logs on disk
# for logs that are bigger than the given size, or disables that
# completely if set to False. The default value is 4096, which should
# be a reasonable default on most file systems. This setting has no
# impact on status plugins, and merely affects the required disk space
# on the master for build logs.
#
# The logCompressionMethod controls what type of compression is used
# for build logs. The default is 'bz2', and the other valid option is
# 'gz'. 'bz2' offers better compression at the expense of more CPU
# time.
#
# The logMaxSize parameter sets an upper limit (in bytes) to how large
# logs from an individual build step can be. The default value is
# None, meaning no upper limit to the log size. Any output exceeding
# logMaxSize will be truncated, and a message to this effect will be
# added to the log's HEADER channel.
#
# If logMaxSize is set, and the output from a step exceeds the
# maximum, the logMaxTailSize parameter controls how much of the end
# of the build log will be kept. The effect of setting this parameter
# is that the log will contain the first logMaxSize bytes and the last
# logMaxTailSize bytes of output. Don't set this value too high, as
# the the tail of the log is kept in memory.
c['logCompressionLimit'] = 16384
c['logCompressionMethod'] = 'gz'
c['logMaxSize'] = 3*1024*1024 # 3MiB
c['logMaxTailSize'] = 32768