Demonstrate the Bundler::GemfileNotFound thrown during fetch_path_gemspec_paths. See initial discovery.
In ::Dependabot::Bundler::FileFetcher::fetch_path_gemspec_paths, if a Gemfile.lock or gems.locked exists, an instance of ::Bundler::LockfileParser will be initialised.
This cascades down to a raise GemfileNotFound. There is no rescue ::Bundler::GemfileNotFound in ::Dependabot::Bundler::FileFetcher::fetch_path_gemspec_paths.
Per the example workflow, ::Bundler::GemfileNotFound is thrown during ::Bundler::LockfileParser.new(...) for directories that do contain a Gemfile, that dependabot's file fetcher is able to find, independent of ::Bundler.
So running the bundler file fetcher on a directory with a lockfile will end up with dependabot throwing a ::Bundler::GemfileNotFound. Unless a Gemfile exists in the directory that the script is being run from. Or unless a BUNDLE_GEMFILE environment variable is set to any garbage value.
The inverse call stack to the point that the ENV["BUNDLE_GEMFILE"] is read is
::Bundler::SharedHelpers::find_gemfile::Bundler::SharedHelpers::root::Bundler::root::Bundler::app_cache- With a default input
custom_path = nilthat if set would bypass the call to root;path = custom_path || root.
- With a default input
::Bundler::Source::Rubygems::cache_path::Bundler::Source::Rubygems::initialize::Bundler::Source::Rubygems::from_lock::Bundler::LockfileParser::parse_source::Bundler::LockfileParser::initialize::Dependabot::Bundler::FileFetcher::fetch_path_gemspec_paths
A search of bundler's use of caches and of its use of cache_path don't make it immediately obvious why there needs to be an error if the path can't be found, despite the benefit of the doubt that it's used somewhere else to know where to look for and open the Gemfile.
Raised as tech-debt in dependabot/dependabot-core#7273.
Raised as feature request in rubygems/rubygems#6671.