Local PATH entries in Gemfile.locked cause 500 server error

[svoop]

We have a few local vendored gems (unreleased or not yet released gems) in our Rails app such as:

# Gemfile

gem "pg_i18n_attributes", path: "vendor/gems/pg_i18n_attributes"

This translates to the PATH line:

# Gemfile.locked

PATH
  remote: vendor/gems/pg_i18n_attributes

And it seems, Railsbump doesn't like those. Testing them against Rails versions is of course impossible, but instead of throwing a 500 Server Error, maybe just ignore and skip them?

[etagwerker]

@svoop Thanks for submitting this issue! I started this draft PR to reproduce the error: #109

RailsBump raises this error when it finds a PATH in the Gemfile.lock which is not getting rescued properly:

Failures:

  1) LockfilesController POST #create with valid params and Gemfile.lock content has local paths creates a new Lockfile
     Failure/Error: @lockfile = Lockfiles::Create.call(lockfile_params.fetch(:content).strip)

     Lockfiles::Create::Error:
       Gemmies::Create::NotFound
     # ./app/controllers/lockfiles_controller.rb:7:in `create'
     # ./spec/controllers/lockfiles_controller_spec.rb:44:in `block (6 levels) in <main>'
     # ./spec/controllers/lockfiles_controller_spec.rb:43:in `block (5 levels) in <main>'
     # ./spec/rails_helper.rb:49:in `block (3 levels) in <top (required)>'
     # ./spec/rails_helper.rb:48:in `block (2 levels) in <top (required)>'
     # ------------------
Add GitLab's Gemfile.lock which has local path
     # --- Caused by: ---
     # Gems::NotFound:
     #   This rubygem could not be found.
     #   ./app/services/gemmies/create.rb:39:in `call'

Finished in 37.1 seconds (files took 1.09 seconds to load)
41 examples, 1 failure, 2 pending

Failed examples:

rspec ./spec/controllers/lockfiles_controller_spec.rb:40 # LockfilesController POST #create with valid params and Gemfile.lock content has local paths creates a new Lockfile
Add a spec to test behavior with a Gemfile.lock with local path

It will never find it, so this should be interpreted as: If I can't find the gem, because it's a vendored gem, or because it is a gem in a private repository, then I can't tell you whether it is compatible or not. 💯

Testing them against Rails versions is of course impossible, but instead of throwing a 500 Server Error, maybe just ignore and skip them?

Yes, agreed. I think it should be immediately marked as "inconclusive" which is a possible status for a compatibility check:

https://github.com/railsbump/app/blob/main/app/models/compat.rb#L4-L9

[etagwerker]

@svoop I believe this is now solved. It should show the "inaccessible gemmies" as "inconclusive" because at the moment we have no way of checking whether they're compatible with anything... Please reopen this if it is not solved. Thanks! 🙏🏼