Buildbot

= Polygame Buildbot Infrastructure =

In order to facilitate developing, building and maintaining consistent versions of current games to multiple platforms, a system of code repositories and a buildbot continuous integration infrastructure has been setup.

Goals:
 * Support software development.
 * Maintain consistent software versions on multiple platforms.

THIS PROJECT IS STILL WORK IN PROGRESS.

Scheme
Basic idea:
 * 1) Code is stored in Code Repositories.
 * 2) Repositories are hooked to BuildMaster.
 * 3) BuildMaster runs BuildSlaves on multiple platforms.
 * 4) Each BuildSlave checks out Code from Code Repositories and builds a Package for that particular platform.
 * 5) Built Packages are stored in Package Repositories.


 * Code Repositories are open to developers. If you want an account, ask Syke or Riba to arrange it.  We're open for all Aalto students and Finnish gamers in general.
 * Package Repositories are open to end-users.

Implementation
Management end of the system runs on Braun.dy.fi:
 * Code Repositories are handled with git-over-ssh on Braun.dy.fi.
 * Code Repositories have a web-interface (git-web)
 * Buildbot BuildMaster runs on Braun.dy.fi.
 * Status interface is available at http://braun.dy.fi:8010/
 * Package Repositories are served from Braun.dy.fi.
 * Debian/Ubuntu packages from: deb http://braun.dy.fi/deb distro main
 * Raspbian packages from: deb http://braun.dy.fi/raspbian wheezy main
 * Fedora/OpenSUSE packages from: http://braun.dy.fi/rpm

BuildSlaves are somewhat distributed:
 * Set of buildslave virtual machines on keystone (Riba's comp)
 * Dedicated Raspberry Pi board running Raspbian distribution.
 * Pandaboard running Debian/Wheezy ARMHF, with Debian/Wheezy ARMEL in chroot.
 * MacMini G4 running Debian/Wheezy PowerPC. (Or a PS3?)

Setting up a BuildSlave
This is a short tutorial on setting up a BuildSlave.

mkdir /home/buildbot buildslave create-slave -r /home/buildbot/buildslave NAMEOFTHEMASTER NAMEOFTHESLAVE PASSWORDOFTHESLAVE chown buildbot /home/buildbot/buildslave chgrp buildbot /home/buildbot/buildslave/buildbot.tac chmod g+w /home/buildbot/buildslave/buildbot.tac nano /home/buildbot/buildslave/info/* SLAVE_ENABLED[1]=1 SLAVE_NAME[1]="NAMEOFTHESLAVE" SLAVE_USER[1]="buildbot" SLAVE_BASEDIR[1]="/home/buildbot/buildslave" SLAVE_OPTIONS[1]="" SLAVE_PREFIXCMD[1]=""
 * Install Buildbot, preferably recent (0.8.x)
 * On Debian/Squeeze, a version from Debian/Wheezy was backported.
 * If system doesn't create a dedicated user for buildbot, create one yourself.
 * For example, "adduser buildbot".
 * Create build-slave instance to suitable directory
 * As root, run following commands
 * For convenience, edit metadata:
 * Hook the BuildSlave to startup scripts
 * On Debian, add following to /etc/default/buildslave and run "/etc/init.d/buildslave start"

Setting up a Code Repository
TODO: User management?

/usr/share/buildbot/contrib/git_buildbot.py $1 $2 $3
 * Make a bare git repository.
 * Push your code there.
 * Add following code to post-receive hook (repo.git/hooks/post-receive), make it executable
 * 1) !/bin/sh

Errata
There are some annoying features in programs. Bugs are often fixed upstream but distributions are reluctant to bump versions of stable releases. (Just the thing this project is trying to subvert..) Here is a list of bugs and workarounds:


 * Problem
 * Steps for solution

Post-scriptum
Basically we could've used GitHub or similar for Code Repositories but keeping the repositories on our own computers is not much additional trouble and spares us from being tied into commercial third-parties. Don't be alarmed of this policy, we fully approve use of GitHub to develope and distribute open source software. It's simply a trivial amount of work that is need up to set up a small number of Code Repositories.

There are some build mechanisms that offer somewhat similar ideas, but the mechanisms are almost always either limited to one OS distribution (like Debian buildd's) or limited to one particular project (like ScummVM buildbot). Using all distribution specific builders would naturally be the most conformant solution, but there is significant work and socializing required to gain access to all the mechanisms. It's easier to act as an independent middle-man.

Fixes and modifications to the projects are naturally preferred to be upstreamed to original authors/projects and/or downstreamed to distribution specific builders.