Use new Travis CI infrastructure

[caniszczyk]

This should speed up builds potentially

http://blog.travis-ci.com/2014-12-17-faster-builds-with-container-based-infrastructure/

Signed-off-by: Chris Aniszczyk zx@twitter.com

[KL-7]

I didn't read through the whole thing yet, but this might be also helpful:

The best news for open source projects is that our build caching is now available for them too. That means faster build speeds by caching dependencies. Make sure to read the docs before trying it out.

For Ruby projects, it's as simple as adding cache: bundler to your .travis.yml.

[KL-7]

Could you also replace MRI 2.1.0 with 2.2.0? Hopefully it doesn't fail. Also, looks like JRuby and Rubinius are the slowest runtimes in our build. I still think we should keep JRuby, but I'm ok with dropping Rubinius until we hear from someone who's actually using TwitterCLDR on Rubinius.

[caniszczyk]

Will do!

It definitely looks like the build speeds up significantly with these changes.

[camertron]

I concur!

[coveralls]

Coverage decreased (-0.28%) when pulling 00328fd on new-travis-ci into cd6d072 on master.

[KL-7]

Oh well, somehow bundler fails to install ruby-cldr on MRI 2.2.0. Feel free to revert it to 2.1.0 and merge, I can look into 2.2.0 issue later.

[camertron]

We shouldn't even need ruby-cldr when running tests, and it's in the :development group. Can we just do something like bundle --without development?

[KL-7]

Looks like removing our custom rubygems installation fixes the issue. I'll update the PR in a second.

FYI, according to this even if you use --without bundler will download the excluded gems.

[KL-7]

Whoa, aside from JRuby, the whole build takes less than 5 minutes to run! Thanks for addressing this issue, @caniszczyk.

JRuby still needs some love though (#124).

[coveralls]

Coverage decreased (-0.8%) when pulling a06a307 on new-travis-ci into cd6d072 on master.

[caniszczyk]

sweet! should we merge this in given that jruby-head is an acceptable failure for now?