Charm Browser
Charm: buildbot-master
Summary
system to automate the compile/test cycle
Charm Store
juju deploy cs:~yellow/oneiric/buildbot-master-3
Owner
yellow
Series
oneiric
Description
The BuildBot is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure. The guilty developer can be identified and harassed without human intervention. By running the builds on a variety of platforms, developers who do not have the facilities to test their changes everywhere before checkin will at least know shortly afterwards whether they have broken the build or not. Warning counts, lint checks, image size, compile time, and other build parameters can be tracked over time, are more visible, and are therefore easier to improve.
Links
Repository   Bugs
lp:~yellow/charms/oneiric/buildbot-master/trunk
Hooks
Interfaces
Provides
Config
extra-packages string
config-user string
buildbot-pkg string
extra-repository string
bucket-name string
config-file string
save-history-now string
config-url string
access-key string
config-private-key string
secret-key string
config-transport string
installdir string
Details
Readme
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".
Changes  
2012/05/01 Gary Poster [r=gary] add subunit to required packages (revno 43)
2012/04/16 Francesco Banconi [r=gary] Only install replacement sources in charms if return code is 100. (revno 42)
2012/04/05 Brad Crittenden [r=gary] If the first call to apt-get has an error, rewrite /etc/apt/sources.list to use standard re (revno 41)
2012/03/20 Brad Crittenden [r=bac] Use new spelling for python-shelltoolbox. (revno 40)
2012/03/02 Francesco Banconi [r=benji] Fixed install_extra_repository. (revno 39)
2012/03/02 Francesco Banconi [r=gmb] upgrade-charm hook. (revno 38)
2012/03/01 Brad Crittenden [r=gmb] Migrate methods from Juju-specific helpers.py module to python-shell-toolbox and handle all (revno 37)
2012/02/29 Francesco Banconi [r=gmb] Added revision file. Removed juju_wrapper. (revno 36)
2012/02/28 Gary Poster [r=bac] move HACKING to README per review (revno 35)
Lint Check
  • err: Charms need a maintainer (See RFC2822) - Name <email>

In other archives
~frankban:oneiric/buildbot-master
 oneiric/buildbot-master