buildbot/metabbotcfg — pull request #3 by jollyroger (2012-05-08 12:13:17+00:00)
Title: Add possibility to test Debian packages building.

Hi, here's a first patch to get metabuildbot create Debian packages. This patch adds additional builders, schedulers and one slave. This patch does just building packages as someone would actually do this by hand. I'll try to unite some buildsteps into one to get more clean view of things. I also tried to minimize impact on other configuration items in metabuildbot. However I couldn't find a proper way to mix in list of builders since there's no obvious reason to invoke several builders (for which triggered schedulers are present) without sending necessary Property values.

# How does this work?
You may see everything in details on [buildbot.homeofus.org.ua](http://buildbot.homeofus.org.ua) (debian builds only) and [metabuildbot.homeofus.org.ua](http://metabuildbot.homeofus.org.ua) (exactly code as in this pull request). Building packages for Debian depends on several tools and repositories.

## Repositories
The repositories [buildbot/debian-buildbot](https://github.com/buildbot/debian-buildbot) and [buildbot/debian-buildbot-slave](https://github.com/buildbot/debian-buildbot-slave) are based on buildbot packages' source distributions (e.g. the one you get running `python setup.py sdist`). Each repository has tags for every released upstream version and relative debian package. There is an upstream branch which holds DFSG-compliant upstream sources (e.g. imported tarball, but non-distributable content is removed). Fortunately Buildbot never had such files in its tarballs (there were some in the repo before, like CorelDraw paintings, but only in the repo). All other branches include debian-specific information like debian/ directory itself. It's common to use master here as a primary debian branch and so it is reserved for packaging buildbot to Debian itself.

To get things working in continious manner (e.g. some debian patches will break the build once the files are moved/heavily changed) and to make possibility for everyone to contribute i've created `unreleased` branch which is used by the buildslave.

When new release is published, all changes in `unreleased` branch will be merged into master branch with everyone mentioned. Then a new bunch of tags will be created and the new iteration begins.

If there would be a need to support some debian/based distribution which will require some changes to get working(like debian-backports which does not have some tools for package building), a new branch is created and maintained.

## Tools

Build process relies mostly on git command-line and `git-buildpackage` tools. It can be used to build packages on several Debian-based distributions from one client using `pbuilder` or `cowbuilder` tools.

# Build process

Currently this type of build will give us building results on specific distributions. Unlike other builders which use git to build project this builder uses tarballs that may indicate that some files are forgotten to be added to distribution.

All these tarballs are transfered between builds by master and stored in public_html/(master|slave) and _not removed_ from master when build is done. This allows you to force rebuild for the builder which actually packages buildbot. But, if space is more important ( it's 4.5 Mb per revision currently) then I'll add another step to clean the tarball. It's ok while there are only two exclusive builders. If there would be several builders on each tarball, then some cron job will be more useful.

Current build steps are not fully configured (e.g. some steps _should_ stop build if failed) and don't have fancy names but hopefully this will be changed in the nearest future.