-
-
Notifications
You must be signed in to change notification settings - Fork 256
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
Invalid caching path with custom BUNDLE_GEMFILE #131
Comments
Thanks for the report. I guess passing an absolute path is an option, but not so nice in the logs, |
Hi! I would like to figure out what bundler should do, and make it do the right thing, but I'm not totally sure at the moment. So I think I would recommend passing an absolute path, to make the action independent of future behaviour. I always thought using a path relative to the Gemfile was weird and surprising, and the However, recently I started to think that the current behavior might be more useful, so maybe it just needs some informative CLI message when these two paths differ and there could be confusion? The reason I think the current behaviour might be more useful is that it allows you to keep an isolated location for each |
so this would require setting custom installation folder for Gemfile if it's set using Does the cache key is generated based on Gemfile.lock? If it is then having |
What I've seen work best with current bundler's behaviour is to put each
you're right. I do recall problems on TravisCI due to this, I guess it didn't generate cache keys based off the lockfile 🤷♂️. Still, it seems like a problem for working locally, specially with future bundler versions, which are expected to install gems locally by default (like npm's With the current "use the Gemfile folder as the base for relative paths", there's a way out of these conflicts like I explained before. |
I used the absolute path approach (dc58db7, test: 0e7d36a), seems the easiest and most reliable.
|
Fixed in https://github.com/ruby/setup-ruby/releases/tag/v1.60.1, thanks for the report. |
In CanCanCommunity/cancancan#682 I found that some gems might depend on the
Which can be solved by adapting the diff --git a/.rubocop.yml b/.rubocop.yml
index 214673a..8f5637e 100644
--- a/.rubocop.yml
+++ b/.rubocop.yml
@@ -37,4 +37,5 @@ AllCops:
TargetRubyVersion: 2.2.0
Exclude:
- 'gemfiles/**/*'
+ - 'vendor/**/*'
- 'Appraisals' But it would have worked without changing that if we use |
hi @eregon I assume and in cancancan AllCops is overriden you can merge overriden config with rubocop's default (https://docs.rubocop.org/rubocop/0.88/configuration.html#merging-arrays-using-inherit_mode)
more here: rubocop/rubocop#288 |
Excluding
Seems much harder to understand, so not sure it's a good trade-off. |
I thought it's excluded because gems were installed in this folder, relative to gemfiles in that folder 🤔 and rubocop checked all gems installed in that folder |
I thought too initially, but it seems it's actually for both reasons. |
Hello,
path to be cached is invalid if env variable
BUNDLE_GEMFILE
leads to subdirectoryexample repo: https://github.com/ErwinM/acts_as_tenant/blob/master/.github/workflows/ci.yml
gemfiles that are used as matrix, gemfiles are located in
gemfiles
subdirectory. Bundler installs gems in./gemfiles/vendor/bundle
, but path to gems is hardcoded to./vendor/bundle
in cache function inruby/setup-ruby
.example of installation in
./gemfiles/vendor/bundle
- https://github.com/ErwinM/acts_as_tenant/runs/1551693162#step:4:156As quick-fix I've set
BUNDLE_PATH_RELATIVE_TO_CWD
, now gems are installed in./vendor/bundle
- ErwinM/acts_as_tenant#245But maybe it will be better to change
ruby/setup-ruby
not to use hardcoded path or setpath_relative_to_cwd
as bundler's config by default or add notice to readmeThanks
The text was updated successfully, but these errors were encountered: