enable bundler caching

[rkh]

Only merge when you are 100% sure you know what your are doing.

[joshk]

I would be in full favour to switch this on by default! (if the config is present of course)

@roidrage @rkh thoughts?

[rkh]

if the config is present of course

This would mean feature flagged repos on org and all repos on com, correct?

[joshk]

not at the moment, the s3 config is per worker not per repo. the plan was to move travis-build to an http api and have the s3 config there, but even then we would need to a way to feature flag and pass this in the hub payload.

I would love to see bundle caching be turned on by default for .com repos at the very least, and would love to see us feature flip this for .org repos.

[rkh]

Well, if we have the build API in place, we could simply have feature flags on the travis-build end (which could also be in the config file, since deploys will become very cheap).

[rkh]

I would love to see bundle caching be turned on by default for .com repos at the very least, and would love to see us feature flip this for .org repos.

Hm. It might be cool to use something like dat-sience or so to enable it for X% of the projects and see what happens.

[sferik]

I’m withdrawing my objection to this pull request based on new behavior in recent versions of Bundler.

👍 for merging this change, assuming the Bundler 1.8 (or later) is part of the default build environment.

[joshk]

@sferik whats the new behaviour?

[sferik]

@joshk bundle install behaves like bundle update when there is no Gemfile.lock.

I’m not sure exactly when that change was introduced to Bundler. I tried to find it in the history but it looks like the --local flag has existed since 2010, so it’s possible I was mistaken when I said bundle install has a bias toward local gems.

[joshk]

Hmmmm, thanks for the info, have you tested it out on a project on Travis to confirm?

[sferik]

@joshk I’ve tested it locally. I can test it on a project on Travis CI now.

[joshk]

That would be super awesome!

Does this rely on Bundler 1.8? or will 1.7 ?

On Mon, Mar 2, 2015 at 10:53 AM, Erik Michaels-Ober
notifications@github.com wrote:

@joshk I’ve tested it locally. I can test it on a project on Travis CI now.

Reply to this email directly or view it on GitHub:
#148 (comment)

[sferik]

👍 It works! (Build)

It seems to work with Bundler 1.7. That said, I’d be happy to see Bundler updated to version 1.8 in the build environment for other reasons.

[joshk]

Ok, but I see it using the cache fine, does it download the latest gem update if one exists though?

[sferik]

@joshk I guess I’ll have to wait for a new dependent gem to be released. I’ll update this issue as soon as that happens.

[joshk]

Cool, thank you, otherwise we can add a bundle update after the install if there is no Gemfile.lock

On Mon, Mar 2, 2015 at 8:03 PM, Erik Michaels-Ober
notifications@github.com wrote:

@joshk I guess I’ll have to wait for a new dependent gem to be released. I’ll update this issue as soon as that happens.

Reply to this email directly or view it on GitHub:
#148 (comment)

[sferik]

@joshk Here we go! ^^

[sferik]

Confirmed!

[joshk]

Welllllll, that is awesome! I'll talk to the team about this!

Thank you so much @sferik !!!!

[sferik]

If you decide the release this, be sure to warn people that vendoring gems could cause issues with code coverage. SimpleCov will include all the vendored code as uncovered, potentially causing the tests to fail. I was able to solve this by adding the following line to spec/spec_helper.rb:

 SimpleCov.start do
   add_filter '/spec/'
+  add_filter '/vendor/'
   minimum_coverage(99.62)
 end

I believe this could be avoided by vendoring the gems into a hidden directory (e.g. .bundle) or a directory outside the build directory (e.g. /tmp). Just something to think about before you release the feature.

[ZurabWeb]

@rkh Needs rebase.

[mvdkleijn]

I was about to enable caching for my bundler / ruby dependencies based on http://docs.travis-ci.com/user/caching/ when I read this...

Is this going to be released soon-ish? If so, I'll wait for it to be automatically enabled.

[joshk]

No sorry, we don't have an ETA on this.

[BanzaiMan]

Closing for now.