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
|
Usage
=====
This charm depends on the buildbot-slave charm.
It expects all configuration to be provided initially at deploy time,
using the --config option.
You can provide a master.cfg file to use inline with your config file,
or you can provide a full branch that includes a master.cfg and any
other desired support files. If you provide a branch, be aware that
this charm expects to control the .tac file.
In both cases, you need to modify your master.cfg file to be used by
the charm.
* The BuildmasterConfig's "slaves" key should usually be an empty
list. This list will be populated by slaves dynamically as they
join. You may be able to also define slaves that are hosted
elsewhere (not in juju). This has not been tested and may need
some adjustments to work.
* The "builders" key should contain instances of
buildbot.config.BuilderConfig, not dicts. The "slavenames"
argument should be a list of a single empty string. The empty
string will be removed and replaced with the names of slaves that
dynamically declare that they want to participate in those builds.
Examples are below.
Demo of a single master.cfg file
--------------------------------
This uses the standard buildbot Pyflakes example.
Start with the buildbot-slave and buildbot-master charm in your charm
repository.
juju bootstrap
juju deploy --repository=./charms local:buildbot-master --config=./charms/oneiric/buildbot-master/examples/pyflakes.yaml
juju deploy --repository=./charms local:buildbot-slave
juju set buildbot-slave builders=runtests
juju add-relation buildbot-slave buildbot-master
Look in the pyflakes.yaml file to see how the master.cfg was modified
as described above.
Demo of a master.cfg in a branch with supporting files
------------------------------------------------------
This is a pretty odd example in several ways, but you can also run a
master and slave that run Launchpad's tests, like so:
juju bootstrap
juju deploy --config=./charms/oneiric/buildbot-master/examples/lpbuildbot.yaml --repository=./charms local:buildbot-master
juju deploy --config=./charms/oneiric/buildbot-slave/examples/lpbuildbot.yaml --repository=./charms local:buildbot-slave
juju add-relation buildbot-slave buildbot-master
Note that starting up the buildbot-slave for Launchpad takes a very,
very long time (over two hours) and requires a large EC2 instance to
avoid out of memory errors.
Running the charm tests
=======================
1) Establish a charm repository if you do not already have one. A charm
repository is a directory with subdirectories for each Ubuntu version being
used. Inside those per-Ubuntu-version directories are the charm
directories. For example, to make a charm repository for this charm under
Oneiric follow these steps:
a) mkdir -p ~/juju-charms/oneiric
b) ln -s `pwd` ~/juju-charms/oneiric/buildbot-master
2) Copy the juju_wrapper file into some place earlier in your PATH than the
real juju executable, naming it "juju". Edit the CHARM_TEST_REPO variable
therein to reflect the location of the charm repo from step 1.
3) Bootstrap the juju environment if not already done:
juju bootstrap
4) Run the tests: RESOLVE_TEST_CHARMS=1 tests/buildbot-master.test
XXX bac 2012-02-23: The tests do not run locally using precise. Set
default-series: oneiric to get them to pass.
Running the charm helper tests
==============================
Just run "python hooks/tests.py".
|