What is Travis CI

A distributed build system for the open source community

Goals

Travis is an attempt to create an open-source, distributed build system for the OSS community that:

1. Allows open-source projects to effortlessly register their GitHub repository and have their test suites run after pushes
2. Allows users to contribute build capacity by connecting a machine that runs Travis workers and VMs they use on their underused servers

With Travis CI our vision is to become for builds (i.e. tests, for starters) what services like rubygems.org or Maven Central are for distribution of libraries.
We strive to build a rock solid, but dead-easy to use open-source continuous integration service for the open source community.

See It In Action

You can see Travis CI in action at travis-ci.org. With about 1 year in operation, we have some prominent open source projects trusting travis-ci.org to run their continuous integration:

• Ruby on Rails, Bundler, Sinatra, Rack, RSpec, Cucumber, HAML and SASS, RubyGems, rubygems.org, Mongoid, Rubinius, Factory Girl, Spree, Devise, amqp gem and even GitHub mirror of CRuby (MRI) itself in the Ruby community
• Node.js, npm, Express, Vows, Mocha, Ember.js (ex. SproutCore 2), Batman.js and numerous flatiron subprojects in the JavaScript community
• Symfony 2, Doctrine 2, Composer, Behat and numerous Symfony 2 bundles in the PHP community
• Leiningen, Midje, clj-time, Knockbox, Langohr, Monger, CongoMongo, Neocons, Sumo in the Clojure community
• Cowboy and Elixir in the Erlang community
• Riak Java client, Cucumber JVM, Symfony 2 Eclipse Plugin in the Java community
• Scalding and Scalatra in the Scala community
• Tornado, simplejson, Fabric, Requests, Kombu in the Python community

We Are Not Done Yet

Please note that this is a work in progress. We have only reached our goal #1 so far. We try to follow the 80/20 for requirements. I.e. we focus on the most common use cases.

Travis CI is not currently a good fit for closed in-house installations: there are multiple applications that evolve
rapidly and workers need VMs running on the same host. Ask on the IRC channel for more information.

You can also watch this (a year old but still valid) screencast to get an idea: 1:20 quick demo screencast

Get In Touch!

• Repositories Github
• Twitter
• IRC
• Mailing list

User Documentation

We care about our documentation and make sure our documentation guides are clearly
written and up-to-date. Please make sure you read them. Two key guides are

• Getting started
• Build Configuration

and we also have guides technology-specific guides:

• Clojure
• Erlang
• Node.js
• PHP
• Ruby

Technical Overview

Travis consists of several parts:

• An Ember.js-based single-page application that runs client side.
• A Rails 3 application that serves to the in-browser application and takes pings from Github.
• A JRuby and AMQP powered worker for running a project’s test suite in snapshotted virtual machines.
• A websocket server (we use Pusher) for tailing build results to the browser.
• A JRuby-based AMQP daemon that collects build reports, workers state, propagates them to Pusher, delivers notifications and so on.
• Chef cookbooks that are used to provision the Travis CI environment (to provide databases, RabbitMQ, Rubies/JDK/Node.js versions and so on) and tools that build VM images.

All these applications, tools and libraries are hosted under Travis CI github organization.
This particular repository is the site that powers travis-ci.org.

A more detailed overview is available in our Technical Overview guide aimed at developers.

Setting server environment up

The setup consists of 4 steps:

$ bundle install
$ bundle exec rake travis:setup:config

This will create two files: ./config/travis.yml and ./config/database.yml. Edit these files according to your local configuration.

Travis CI is configured to authenticate with OAuth and github. You’ll need to register your application with github (even if it’s only for local development) and complete all the required fields in ./config/travis.yml for your ID and secret.

Next, tell Travis to configure the database:

$ bundle exec rake travis:setup

And finally start the server:

$ bundle exec foreman start

Note that you always start the server using foreman, not unicorn or webrick

Travis CI is now up & running on http://localhost:5000

You can also create a default admin user (optional):

$ rake travis:create_admin_user

Application is now up & running on http://localhost:5000

Working on the server

Running the tests

Integration tests are implemented using Jasmine and can be run in the browser:

$ RAILS_ENV=jasmine rake db:migrate db:seed
$ rails s thin -e jasmine
$ open http://localhost:3000

To run the whole test suite simply do:

$ bundle exec rake spec

In order to run all tests you need to have ChromeDriver installed. You can download it here and then place it somewhere on your PATH.

Dependency Status

Developer Documentation

Please keep in mind that Travis CI evolves rapidly and this documentation may be outdated. Development, travis-ci.org maintenance and
user documentation take priority.

• travis worker

History

Design Iterations

• Second design Feb 2010
• First design Jan 2010
• Initial mockups of index and details

Other sources

• Travis CI – Video: Presentation at Boston.rb (Jeremy Weisskotten)
• Travis – a distributed build server tool for the Ruby community – Introductory blog post about the original idea (Sven Fuchs)

Requirements

• Ruby 1.9.2 (Ruby 1.9.1 is not supported)
• PostgreSQL for the pg gem
• RabbitMQ
• VirtualBox 4.1