Ensure absolute lockfile remotes for gems nested inside project #2799
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
I discovered this problem while working on #2774 and I frankly don't understand how it wasn't surfaced before.
We were checking for a leading dot to perform remote relative path correction, but when you have gems nested inside a project, the relative path may not necessarily begin with a dot.
For example, if you have this in your Gemfile
Then the remote won't necessarily be
../gems/nested
. It might just begems/nested
, which is also a relative path. We need to convert those into absolute paths too, otherwise setting up the composed bundle fails.Implementation
I started using
URI
to check if the remote has a scheme. If it has a scheme, likehttp
, then we don't want to perform any corrections.If it has no scheme, then it's a file path and we can turn it into absolute.
Automated Tests
Added a test that doesn't pass before the fix.