Using an outdated cache instead of none


#1

Requested here

There are many instances where using a primed cache is better than not using one at all. It would be awesome if we could use the “wrong” dependency cache to speed up installing dependencies.


#2

Users can already do this by referring to a file that stays the same. I’ll give an example from the Ruby world since that’s what I know best.

A Gemfile specifies dependencies and maybe their versions, but maybe not. A Gemfile.lock specifies dependencies and versions last installed. Suppose a user specifies no version for rspec in his Gemfile. He runs bundle install and will get the latest version of rspec on each build. This will change the hash of Gemfile.lock in the build from what’s committed. That can be cache-saved but never cache-restored, as that particular Gemfile.lock hash won’t be known to the builder until after dependencies have been updated.

But, the user can cache based off of either Gemfile or Gemfile.lock. If capybara was specified with version 2.0.0, that will be cached and not installed when he runs bundle install. That’s partial caching. I believe it’s the most caching the user can accomplish without committing a version for each dependency.


#3

I just moved that entire thread into a feature request here so that other folks with similar needs can find and discuss it.


#4