Support running bundle install with the --full-index option

[Skenvy]

I have circumvented an issue trying to install a recent gem that gives me an error

Downloading <gem-xyz> revealed dependencies not in the API or the lockfile

Where running the install with --full-index fixes this. I can't see a way to pass this option directly to the part of this action that runs the bundle install step, and so trying to use the action with the bundler-cache: true fails with the same error ~ revealed dependencies not in the API

[eregon]

In my understanding one should never need --full-index, please report the issue to Bundler.
Maybe committing the Gemfile.lock after bundle install --full-index locally would solve it.
There might also be an env var for --full-index which would allow you do to do what you asked.
Closing because this needs some clarification from Bundler side, and anyway I wouldn't add an option for such an edge case.

[Skenvy]

I am not confident I understand the issue enough to properly diagnose a more specific place to raise the issue, other than knowing that using --full-index solved my problem locally, and the option to pass arguments to bundler in this action is as far as I could tell, limited to env vars that bundler will read (and the closest I could find to --full-index being available as a passable env var was this issue rubygems/rubygems#3806) -- it's reasonable that this request probably isn't the nicest way to achieve it, although an option to directly pass cli args to the bundler invocation outside of the passable env vars would be handy I can appreciate why you might not want to surface that.

Maybe committing the Gemfile.lock after bundle install --full-index locally would solve it.

I did this -- locally ran with --full-index and committed my Gemfile.lock -- although while reading this to see if the option could be passed in another way, I couldn't see --frozen option being set anywhere, or the bundle config setting frozen, so afaik it's not solely relying on the lock. Perhaps adding an option to set bundle to frozen might be worthwhile.

There might also be an env var for --full-index which would allow you do to do what you asked.

Would be handy if there was one but I had a look and couldn't find one, only a feature request.

For context the gem I was trying to install was dependabot-omnibus version 0.299.1 which introduced dependabot-uv as a dependency (and the first published version of that gem) -- and I did also test locally running --full-cache with both dependabot-omnibus and dependabot-uv as direct dependencies to generate the Gemfile.lock, then to be certain I'd cleared the cached index, reinstalled ruby, and tried installing with frozen set, so it should have relied solely on Gemfile.lock, but it came back with the same error that Downloading <gem-xyz> revealed dependencies not in the API or the lockfile and would only be resolved again by running it with --full-index -- making that appear the only actually viable fix, at which point I raised this request.

In the meantime or at least until --full-index isn't needed for that version or a newer version I'm ok using a lower version, but I'm not sure how else to fix this besides either passing this option through to the cli args to the bundle invocation in this action, or setting it as an env var for bundler to read when it executes, which would be a feature request on bundler.

[eregon]

I am not confident I understand the issue enough to properly diagnose a more specific place to raise the issue

As I said the proper place to report that is the Bundler issue tracker.
And the discussion in rubygems/rubygems#3806 makes it sound like --full-index shouldn't be used anymore, so if there is a need for it in some case it should be reported as an issue there.

This is not a proper place for Bundler bugs, and I would only consider introducing a workaround here if there is no other way and it has been reported upstream, hence why I closed this issue.

I couldn't see --frozen option being set anywhere,

It's automatically set if there is a committed Gemfile.lock.

[Skenvy]

All reasonable points. I'm just providing the full context for anyone that stumbles on this if someone else searches for --full-index in this repo's issue tracker. The rest of this is just a context dump.

The discussion on that rubygems issue more revolves around gemstash than --full-index, its primary relevance was as the only place someone had requested (e.g. to show that a feature request existed that wasn't completed yet/ever) something akin to setting --full-index in an env var. I wasn't needing to use --full-index for a privately hosted gem, I had needed to use it to pull from rubygems (a gem whose first upload had only been several hours earlier at the time, dependabot-uv @ 0.299.1), so the rest of that issue wasn't abundantly relevant.

I avoided the issue by just using the immediately prior version of the parent gem that didn't have that as a dependency, so I'm fine until it sorts itself out.

I only raised the issue after an hour or two of testing the various pathways to different outcomes of bundle install I described in the comment above, but the summary is that there was different outcomes depending on whether I had bundle config set frozen true or false and running --full-index then running the frozen install in a fresh ruby install didn't circumvent the need for --full-index to let the frozen install complete.

I don't understand it enough to know what kind of bundler issue it would even be to raise it as an issue on their tracker board, because it didn't seem like anything was behaving differently from what docs I could find said about running with --full-index or frozen, so I'm not sure it is a bug for them, because they could easily just say that this is what --full-index is a stop-gap for.

It's raised as an issue on the gem publisher by now anyway dependabot/dependabot-core#11731

Perhaps the best way this request could have been phrased would have been to ask about decoupling the choice to cache gems with actually running the install.

[eregon]

I don't understand it enough to know what kind of bundler issue it would even be to raise it as an issue on their tracker board

--full-index is using the old API, it should never be needed anymore, as discussed in the issue you linked it's considered to be deprecated.
IOW, my understanding is Bundler should never need --full-index for correctness (maybe it's useful for performance in some rare cases).
So based on that already it's worth reporting to Bundler, please do so, you can leave it open-ended as a discussion or so if you are unclear whether it's a bug (I think it's clearly a bug, but I might be wrong).