Rebund for 4x faster Travis builds

Running bundle install to get all gems ready is often the longest part of a build. Any Rails application will depend on tens of gems; and any gem, besides dependency, may have a fairly large build matrix.

Rebund can easily cut your build times by 75%, saving you time and saving the good folks at Travis CI some money.

Example for an application, appfab.io (5.3x speedup):

Example for a gem, fuzzily (2.7x speedup):

Rebund is an alernative to bundle_cache, which didn’t work well enough for us on Travis because it relies on gems to be installed (which partly defeats the purpose).

How it works

Before your build, Rebund checks with a file server if there’s a bundle already available for your current Ruby VM and version of the Gemfile.lock. Technically, it hashes the output of ruby --version and the lockfile.

If there is one, it downloads and unpacks it, then making bundle install blazing fast.

After the build, Rebund packages the bundle (if changed) and uploads it for future uses.

Compared to Travis’ own caching?

Travis provides a similar caching mechanism; unfortunately it’s not available for public repositories.

While implementation details are not public, it seems roughly as efficient as using Rebund. It’s a bit less conservative than Rebund on changes to the Gemfile, too, meaning it’s reuse a branch’s previous bundle if any.

We’ve consciously avoided doing this to avoid difficult-to-debug errors related to upgrading gems.

Using Rebund

Head on to the rebund repository for installation details!