Merge pull request #28 from sol/master

Haskell: Run `cabal update` before running any other scripts
if an exception is raised during a test run then return a 0 result
improve the error message displayed when an exception is raised during the build
oops, 1 should be returned on a failed build :/
i am not entirely happy with this approach, but this tests the timeout and output limit exceptions correctly, some cleanup should be applied in the future
added a vm_stall method, not fully happy with this but it is needed
Export TRAVIS_PULL_REQUEST_NUMBER
Merge pull request #29 from travis-ci/pr-number

Export TRAVIS_PULL_REQUEST_NUMBER
Export TRAVIS_JOB_ID
Add pull_request_number to Commit and add missing tests

pull_request_number should be in Commit, but there was no integration
tests that would catch this error. This commit fixes the situation and
contains tests that ensure that pull requests work as expected.
Merge pull request #30 from travis-ci/job-id

Export `TRAVIS_JOB_ID`
quieten the logging a little
Merge branch 'master' of https://github.com/travis-ci/travis-build
improve the logging while also shipping technical debt!
if a vm stalls don't fail the build
Add a way to switch between virtualenvs with and without --system-site-packages installed

We previously created only one virtualenv per Python, without --system-site-packages. However,
some dependencies cannot be installed via pip. So in the end we settled on having two sets
of virtualenvs and the way to alternate between them.

Depends on travis-cookbooks@54f5ad4f0e43438fee83efc08b30d88bc558839d being deployed.
Merge pull request #31 from travis-ci/mk-two-sets-of-virtualenvs

Add a way to switch between virtualenvs with and without SSP
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.
A typo
Cosmetics