cache path is hard-coded, can't be set by user

[dgholz]

Hi, I wanted to save and restore to a file outside of vendor. I wanted to use Brakeman to scan my app, and include some code from one of my gems, and Brakeman by default excludes any files in vendor (even if they are explicitly added as paths to scan).

I'm dealing with Brakeman, but I was disappointed when I tried to set BUNDLE_PATH to change where the gems were installed, and the action ignored it. It would be nice for the action to support the standard Bundler environment variables, especially BUNDLE_PATH

[eregon]

Duplicate of https://github.com/ruby/setup-ruby/issues/136#issuecomment-753613782, see reasoning there. What's the issue to use the standard Bundler path, which is vendor/bundle?

It sounds an issue of Brakeman which should have a way to force scanning under vendor/bundle when that's desired.

[dgholz]

What's the issue to use the standard Bundler path, which is vendor/bundle?

I think you understand, but because you asked: it's a limitation of Brakeman, that it rejects paths that have vendor in it. So I can't tell it to include the contents of a gem in its analysis.

I'm raising this with Brakeman separately. I'm raising this here because I thought I could set the path to something else (which I already know how to do with my knowledge of Bundler) and was sad when I found https://github.com/ruby/setup-ruby/blob/359bebbc29cbe6c87da6bc9ea3bc930432750108/bundler.js#L122

I just wanted to set it to gems.

Brakeman which should have a way to force scanning under vendor/bundle when that's desired.

Brakeman already has an option to scan vendor (with --no-skip-vendor), it's just not very helpful since it scans and warns on all the gems you're using. I'm raising this issue with Brakeman separately. I raised this issue because I feel like it would be a small fix, easy to reason about, and would let people reuse their knowledge of Bundler.

[eregon]

I think it would be OK to use the value of BUNDLE_PATH if set to a relative path. It should be an error if it's an absolute path though, as that makes it super messy to clean up or reason about. The bundler path should then be part of the cache key. PR welcome.

[januszm]

Has anyone noticed occasional problem with the conflict between the app installed gems and defaults from Ruby when using bundler-cache: true? When turned off, this disappears (requires adding bundle install somewhere).

/opt/hostedtoolcache/Ruby/3.0.3/x64/lib/ruby/gems/3.0.0/gems/bundler-2.3.6/lib/bundler/runtime.rb:309:in
`check_for_activated_spec!':
You have already activated digest 3.0.0, but your Gemfile requires digest 3.1.0.
Since digest is a default gem, you can either remove your dependency on it or try updating to a newer version of bundler that supports digest as a default gem.
(Gem::LoadError)

same for io-wait and others (if you downgrade one gem to version matching the one from Ruby, it will start complaining about others from the list.

[eregon]

@januszm That seems completely unrelated, please file a separate issue if still a problem. Gems are never shared between Ruby versions with bundler-cache: true, so it sounds like you're missing a bundle exec or so.

[januszm]

@januszm That seems completely unrelated

Gotcha, it was actually caused by the "spring" preloader, after the last update, I had to remove it from the project now because it caused the problem as above when used with bundler-cache: true in GH Action

[Fryguy]

@dgholz I stumbled back around to this, but brakeman has been fixed to handle not removing explicitly referenced paths, which I think solves your problem with vendor being excluded.

[eregon]

I'll tentatively close this, it's unclear if worth the extra complexity and length in the cache key. vendor/bundle seems pretty standard.