etagwerker
commented
1 week ago @svoop Thanks for submitting this issue! I started this draft PR to reproduce the error: https://github.com/railsbump/app/pull/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
We have a few local vendored gems (unreleased or not yet released gems) in our Rails app such as:
This translates to the PATH line:
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?