When we run our build suites on Travis Pro the bundling step takes the most time by a wide margin (aside from the test script itself).
Inspired by this Coderwall protip by Michał Czyż, I set about attempting to cache our completed gem bundle on S3.
Update: Checkout the bundle_cache gem for an improved version of this technique
How it works
- The tarballed bundle and a SHA-2 sum of the
Gemfile.lock are downloaded from S3 (if they exist)
- Travis runs
bundle install as normal (except that the bundle is installed to
~/.bundle). This shouldn’t take more than a few seconds if the bundle hasn’t changed.
- Travis executes all the normal build steps, as usual
- The bundle is tarballed and uploaded to S3 (us-east is the closest region to the new Travis workers), but only if the SHA-2 hash for the
Gemfile.lock has changed
The bundle is uploaded with
public-read permissions for easier downloading. This should not be a problem for most people and could be mitigated by using a really obscure filename, like a UUID.
Step by step instruction
- Set up a bucket on S3 in the US Standard region (
us-east-1) (and possibly a new user via IAM)
- Install the
travis gem with
gem install travis
- Log into Travis with
travis login --auto (from inside your project respository directory)
- Encrypt your S3 credentials with:
travis encrypt AWS_S3_KEY="" AWS_S3_SECRET="" --add (be sure to add your actual credentials inside the double quotes)
- Add the
bundle_install.sh files from below to the
- Modify your
.travis.yml file to match the
BUNDLE_ARCHIVE variable will be used as the base for the uploaded bundle’s name
AWS_S3_REGION is optional and defaults to
- Pay special attention to these keys:
If you have any questions or comments, you can comment on my gist, or tweet at me on Twitter.