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