How to quickly set up Travis CI for your Ruby application


![travis screencap](

The short version:

If you want your Travis build to go faster and you use [`bundler`]( in your Ruby project, try adding this to your `.travis.yml`:

> `cache: bundler` > `sudo: false`

The long version:

[Travis CI]( is a service that automatically runs a test suite when you push code to GitHub. (You can customize the events that trigger builds, but that’s the general idea — continuous integration linked to version control.) The GitHub repository for Sunlight’s Parmenides project, for example, has its build status showing in [its README](

Setting up Travis is a simple, [well-documented process]( — you basically just need to drop a `.travis.yml` in a public repo — but things slow to a crawl if Travis has trouble building the environment for your tests (this is set up in `.travis.yml`). It takes a long time to discover stuff like missing configuration settings and malformed migration files if you have to build a whole virtual environment to do it. That means you might get stuck in 10-minute debug cycles like [this](

While it’s probably best to think things through in your local environment, there’s a way to speed up your Travis builds: [Cache your dependencies]( and use Travis’ container-based infrastructure. Just add these two lines to your `.travis.yml`:

> `cache: bundler` > `sudo: false`

The first line tells Travis to cache your bundle so that you don’t have to reinstall every gem on every Travis build. The second line tells Travis to use its container-based infrastructure for your build. We include this because Travis’ free service only allows you to cache dependencies if you use their containerized infrastructure (and because their containerized service is generally [faster](

A word of caution: Caching dependencies means that you’re, well, caching your dependencies. It’s worth remembering that you’ve opted to do this in the event that you encounter strange problems.