This is a setup of Buildbot steps, factories and configuration helpers that give you the best of buildbot and the best of Travis CI:

• Builder configuration that lives with the source code
• Private builds
• SVN and non-github Git support

Basically we provide a compatibility shim in buildbot that allows it to consume a .travis.yml file.

This is still buildbot. Whilst we can move the build definition out of the way, we still need to register a builder and set up change sources. There is a travis.yay in the CI codebase:

projects:
  - name: project1
    repository: https://svn.example.com/svn/customer/project

This is a .travis.yml for a typical buildout project:

language: python

before_install: python bootstrap.py
install:./bin/buildout
script: ./bin/test

You can read more about this file format on the travis-ci website:

http://about.travis-ci.org/docs/user/build-configuration/

But features not also mentioned on this page might not currently be supported.

We only really support python and mandate that you set the language to python. However right now there is nothing python specific going on: your install/script steps can do anything needed.

Travis provides 6 hook points for your builds:

• before_install
• install
• after_install
• before_script
• script
• after_script

We really don't care what you run from these hooks as long as exit code 0 means success and anything else means fail.

You can provide a single command like this:

install: ./bin/buildout

Or multiple commands like this:

install:
  - ./configure
  - ./bin/buildout

Your code is built inside a VM and is thrown away after a build. Thus it is granted passwordless sudo. This is also true of Travis. Tempting as it was to add a new dependencies list to .travis.yml we stay compatible and suggest you add before_install steps:

before_install:
  - sudo apt-get update
  - sudo apt-get install -y -q mydependency

The update ensures that the package index is up to date - without it you may get "package missing" errors. You pass -y to the install command so that it doesn't prompt for human input.

You might want to perform multiple builds of the same piece of software. Travis delivers:

env:
 - FLAVOUR=blue
 - FLAVOUR=green
 - FLAVOUR=red

install:
  - ./configure -f $FLAVOUR
  - ./bin/buildout

Commits to this code base will cause builds for blue, green and red flavours. The environment variables can be used like ordinary environment variables inside the scripts you run from your .travis.yml and can be used in the .travis.yml itself.

env is a list of environment variables. You can specify multiple variables on a single line like this:

env:
 - PROP1=foo PROP2=bar

Your options for language and env create an implicit build matrix. A build matrix is a collection of all the possible combinations of the env options and language versions. You can fine tine this matrix by excluding certain combinations, or inserting additional ones.

Here is an example of excluding a combination and inserting an additional build:

python:
  - 2.6
  - 2.7

env:
  - FLAVOUR=apple
  - FLAVOUR=orange

matrix:
  exclude:
    - python: 2.7
      env: FLAVOUR=orange
  include:
    - python: 2.7
      env: FLAVOUR=banana

This will do an additional build of the banana build but only for python 2.7. And it will turn off the build for the orange flavour, again only for python 2.7.

If you want to black list a set of branches:

branches:
  except:
    - legacy
    - experimental

And if you want to white list a set of branches:

branches:
  only:
    - trunk
    - /^deploy-.$/

If you specify both then except will be ignored.

Names surrounded by / are treated as regular expressions. They will be handled by the python re module and might behave differently to travis, which uses ruby.

This repository contains a set of HtmlResource classes for implementing a UI that works somewhat like the /console view.

The root resource is Projects. It provides a simple list of registered projects which are colour coded to indicate the state of the build.

When a user drills down in to a particular project they see a ProjectStatus view. This is basically a list of commits with colour coding to indicate whether the corresponding build was successful or not.

Drilling down to a particular revision reveals a Build view. Of particular interest here is the build matrix which shows a summary of all the builds this commit triggered. A detail view of each build follows on he same page.

This is really not something djmitche has in mind when he fires up vim and starts hacking on buildbot :)

The basic behaviour is:

• Commit is picked up (polling by default, with additional triggers via /change_hook/poller?poller=pollername web hook
• Build is scheduled on a 'spawner' builder - this is a builder configured to use an ordinary slave
• Checkout occurs - for the purposes of acquiring the .travis.yml rather than for actually performing a build
• 'spawner' triggers a build on a 'job' builder for each environment in the build matrix defined in .travis.yml
• A custom mergeRequests handler is provided that considers build properties from .travis.yml when decided if builds can be merged.
• 'job' builder does a single build in a clean VM
• setup-steps step dynamically appends ShellCommand steps based on contents of .travis.yml
• when job is over VM is thrown away.
• The 'spawner' build acts as a way of aggregating the build results in a single pass/fail status.
• MailNotifier subclass uses .travis.yml found in build history so that recipients list and whether or not to mail can be adapted accordingly.

Don't. She's not ready.