travis-ci/travis-build — pull request #32 by michaelklishin (2012-08-20 10:57:33+00:00)
Title: Support service dependencies (starting services via .travis.yml)

## Background

Historically, projects that need various services (PostgreSQL, MySQL, RabbitMQ, etc) running either
relied on the fact that CI env had them started on boot or `before_install` steps (or similar).

This is about to change.

## The Change

As the number of services grows and more and more large-ish projects join Travis, it becomes more
and more obvious that we cannot have all those services started on boot and have enough RAM for
large test suites.

So we have a few options:

* Add more RAM to each VM
* Tune services to use less RAM
* Disable some services from being started on boot

We have been doing #2 and #3 for some time now but did not touch services that have always been
started on boot (e.g. MongoDB or RabbitMQ). #1 will also happen thanks to our next gen (BlueBox) VM infrastructure.

However, with BB we also move to 64 bit VMs and that largely eliminates some of the gains. The only
realistic scenario seems to be disabling more services on boot, leaving only MySQL and PostgreSQL running
by default.

When we do that, projects will have to tweak .travis.yml to enable those services. Using `sudo service ... start` is straightforward
but has some downsides

* You need to know exact service names. Apparently some developers do not know them and some services have irregular names.
* This makes hundreds if not thousands of .travis.yml files out there contain even more Linux/Debianoids-specific code.

In the end Josh and I settled on providing a way to list services in .travis.yml in a way that will let travis-build
handle irregular service names and (at some future point) OS differences.

## How It Works

``` yaml
services:
- riak # will start a service named riak
- rabbimq # will start a service named rabbitmq-server
- memcache # will start a service named memcached
```

That's about it.