buildbot-travis 0.4.0

Supported languages

The list of supported language is depending on your build worker configuration.

With the help of docker, you can create as many images as you need worker configuration.

Actually the language parameter of the defacto travis format does not fully leverage the full possibilities of what you can do with buildbot.

You could think of selecting a different docker image according to the version of software you want to check. This can avoid the time to setup the worker environment at the beginning of your travis.yml (as you would do in travis saas)

Build Steps

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

Each element of the list in the yaml will create a single step, which is named with the first characters of your command line.

If you want to create a custom name, buildbot_travis supports following syntax:

script:
  - |
      # build
      ./configure
      make
  - |
      # tests
      make tests

Buildbot specific features

Original Travis just create a simple shell script to run the whole CI script. Buildbot is a little bit more powerful, and buildbot_travis can make use of it. For this you need to go out of the travis “de-facto” standard. e.g:

script:

• # build ./configure make

• title: tests condition: TESTS==’tests’ cmd: make tests

If yaml parser encounters a dictionary, then it will use the following keys:

• title: the title of the step in the UI

• condition: a condition to run the step.

  It is evaluated as a python expression, with variables beiing the environment variable generated by your matrix. The condition is evaluated at the time of the parsing of the yaml file. If the condition is not met, then the step is just not inserted in the step list.

• cmd: The command to run.

In order to keep working with buildbot_travis and travis.org at the same time, buildbot travis will look for a .bbtravis.yml before .travis.yml. With this, you can keep your .travis.yml without any buildbot specific feature.

Installing dependencies

The docker image that is used is throw away, and will start from clean state for each build.

You can create a docker image with passwordless sudo, as travis does, so that you can use apt-get:

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

It is however a better practice and more optimized to just provide a prebuilt docker image which contain what you need.

Environments

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

Build Matrix

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.

Deployment

A Deploy section is available in the left side menu. In this section, a Deployment dashboard will be available once configured.

This dashboard enables a streamlined, fully automated delivery process, from Commit to Production environment. Latest version of your project is just one click away from users.

See the dashboard’s template below

DELIVERABLES	STAGES
(projects)	COMMIT	DEV	QA	PROD
Deliverable A	GIT rev	1.2.3	GIT tag	GIT tag

For example, the version 1.2.3 (specified thanks to a GIT tag) of deliverable A is deployed in DEV stage.

Here are the 5 steps to setup a Deployment dashboard in Buildbot Travis.

1. A Deployment section is available in the Settings section. In this section, the Deployment Environment(s) is the list of target environments (or Stages) where deliverables are going to be deployed. These environments should be sorted following your development process definition. Example:

   COMMIT (merged dev), DEV, QA, PROD
   BEWARE!The first column is reserved for COMMIT stage so you do not need to define it in the Stages list.

2. Go to the Deploy section in the left side menu. You should see a Deployment dashboard like the above example. The Stages should be the same as the ones defined in 1).

3. Go to the Settings/Projects section. Add corresponding Stages to the different projects in the Stages field. Stages can be a subset of the Stages defined in 2).

4. You should see a fully configured Deployment dashboard with all the deliverables, Stages, GIT revisions and GIT tags. GIT revisions and GIT tags are available in dropdown lists. When you select a specific version, a pop_up window appears to launch the deployment procedure in the specific stage.

5. To enable push button deployments, you need to define the deployment procedures. Create deployment scripts and update the script and/or after_script sections of the .travis.yml file of each deliverable.

   Example:

   after_script:
      - |
        # Deployment
          python ./deploy.py --repo "${repository}" --stage "${stage}" --version "${version}";
   
          ${repository} is the URL of the project's (or deliverable's) repo.
          ${stage} is the retrieved from the Deployment dashboard.
          ${version} is retrieved from the Deployment dashboard.