-
Notifications
You must be signed in to change notification settings - Fork 723
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add switch for "bundle clean" on "store build cache" #2518
Comments
So, just to verify, using our |
No, it's not an option, because at least in our case in one travis job multiple |
@rkh is there something we can/should do here to improve this? |
Any updates on this? We still have to use workarounds with different bundle paths, which is annoying. |
I would be curious also to hear about progress on this. My scenario:
=> Enforced "bundle clean" caused that direct built in bundle caching logic doesn't work, and I ended up simply using
which works partially (but I presume that it will grow in size when gems change?!?) |
Any progress on this? Using different directories is annoying, since you have sometimes to manually clear the caches, because the suite is broken for no reason. |
@rkh what are your thoughts on this? |
I think it is reasonable. cache:
skip_bundle_clean: true for example. |
The cache:
directories:
- vendor/bundle version should work just fine.
That is true. But it would also be true if we'd implement |
It does. Thanks for the pointer. |
The documentation is now live. https://docs.travis-ci.com/user/caching/#Cleaning-up-bundle |
I'm not sure cause, but due to the influence of `gem clean`, the expected gem seems not to be installed correctly. In order to avoid a test failure due to this, I fixed that `gem clean` not be executed. Ref: travis-ci/travis-ci#2518 (comment) This is a workaround. If Travis fixes something, please revert this.
I'm not sure cause, but due to the influence of `gem clean`, the expected gem seems not to be installed correctly. In order to avoid a test failure due to this, I fixed that `gem clean` not be executed. Ref: travis-ci/travis-ci#2518 (comment) This is a workaround. If Travis fixes something, please revert this.
Background
I'm using multiple Gemfiles in one travis run, e.g.
./Gemfile
,./folder_a/Gemfile
and./folder_b/Gemfile
. To improve the speed of one run, caching for bundle install is advised. Using directory caching (see http://docs.travis-ci.com/user/caching/#With-a-custom-install-step ) this is already possible.Limits to this approach
Sadly right before uploading the cache (
store build cache
), abundle clean
is executed. This means, that all gems, which are not listed in./Gemfile
are removed from the bundle cache. So all gems from./folder_a/Gemfile
and./folder_b/Gemfile
which are not in./Gemfile
are removed. This also implies, that all Gems fromfolder_a
andfolder_b
need to be installed on every travis run, thus defeating the purpose of a cache.Workaround
It's possible to use two different bundle cache folders. One for
./Gemfile
and the other for all the other Gemfiles. This implies, that whenever something is called fromfolder_a
orfolder_b
an additionalENV
variable needs to be set.This is cumbersome and error prune, since forgetting to set the correct
ENV
:bundle clean
will runbundle exec
can not be executed, because the gems where installed into another cache folder.Wish
Please provide a way to disable
bundle clean
duringstore build cache
. This would allow me to use multiple Gemfiles, while using one cache folder.I understand, that
bundle clean
is there for a reason, to ensure, that the cache will not contain unneeded or obsolete files. But it's in our (the customers) interest to keep the cache folder small to improve the speed of a travis run. So a manualtravis cache --delete
once in awhile would be enough.The text was updated successfully, but these errors were encountered: