There are a few simple things you can configure in your .travis.yml to make your travis builds faster for ruby builds. They are oddly under-documented by travis in my opinion, so I’m noting them there.
Odds are your ruby/rails app uses nokogiri. (all Rails 4.2 apps do, as nokogiri has become a rails dependency in 4.2) Some time ago (in the past year I think?) nokogiri releases switched to building libxml and libxslt from source when you install the gem.
This takes a while. On various machines I’ve seen 30 seconds, two minutes, 5 minutes. I’m not sure how long it usually takes on travis, as travis logs don’t seem to give timing for this sort of thing, but I know I’ve been looking at the travis live web console and seen it paused on “installing nokogiri” for a while.
But you can tell nokogiri to use already-installed libxml/libxslt system libraries if you know the system already has compatible versions installed — which travis seems to — with the ENV variable `NOKOGIRI_USE_SYSTEM_LIBRARIES=true`. Although I can’t seem to find that documented anywhere by nokogiri, it’s the word on the street, and seems to be so.
You can set such in your .travis.yml thusly:
env: global: - NOKOGIRI_USE_SYSTEM_LIBRARIES=true
Use the new Travis architecture
Travis introduced a new architecture on their end using Docker, which is mostly invisible to you as a travis user. But the architecture is, at the moment, opt-in, at least for existing projects.
Travis plans to eventually start moving over even existing projects to the new architecture by default. You will still be able to opt-out, which you’d do mainly if your travis VM setup needed “sudo”, which you don’t have access to in the new architecture.
But in the meantime, what we want is to opt-in to the new architecture, even on an existing project. You can do that simply by adding:
To your .travis.yml.
Why do we care? Well, travis suggests that the new architecture “promises short to nonexistent queue wait times, as well as offering better performance for most use cases.” But even more importantly for us, it lets you do bundler caching too…
If you’re like me, a significant portion of your travis build time is just installing all those gems. On your personal dev box, you have gems you already installed, and when they’re listed in your Gemfile.lock they just get used, the bundler/rubygems doens’t need to go reinstalling them every time.
But the travis environment normally starts with a clean slate on every build, so every build it has to go reinstalling all your gems from your Gemfile.lock.
Aha, but travis has introduced a caching feature that can cache installed gems. At first this feature was only available for paid private repos, but now it’s available for free open source repos if you are using the new travis architecture (above).
For most cases, simply add this to your .travis.yml:
There can be complexities in your environment which require more complex setup to get bundler caching to work, see the travis docs.
The existence of travis offering free CI builds to open source software, and with such a well-designed platform, has seriously helped open source software quality/reliability increase in leaps and bounds. I think it’s one of the things that has allowed the ruby community to deal with fairly quickly changing ruby versions, that you can CI on every commit, on multiple ruby versions even.
I love travis.
It’s odd to me that they don’t highlight some of these settings in their docs better. In general, I think travis docs have been having trouble keeping up with travis changes — travis docs are quite good as far as being written well, but seem to sometimes be missing key information, or including not quite complete or right information for current travis behavior. I can’t even imagine how much AWS CPU time all those libxml/libxslt compilations on every single travis build are costing them! I guess they’re working on turning on bundler caching by default, which will significantly reduce the number of times nokogiri gets built, once they do.