Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

Normalize file URIs in spec's lockfiles #7089

Merged
3 commits merged into from
Apr 2, 2019
Merged

Conversation

deivid-rodriguez
Copy link
Member

What was the end-user problem that led to this PR?

The problem was that bumping bundler's version in #7088 made a lockfile spec fail.

What was your diagnosis of the problem?

My diagnosis was that there was a combination of bugs that was making this spec pass, but the spec was incorrect.

What is your fix for the problem, implemented in this PR?

My fix is to change the test version the spec uses to not hit rubygems/rubygems#2595, and thus reproduce the failure. And then fix the spec that was incorrect because the lockfile written had different URLs (file://localhost/<stuff>) from the lockfile we were checking against (file://<stuff>), thus tricking bundle install into thinking something had changed, and thus making it rewrite it with an incorrect bundler version.

Why did you choose this fix out of the possible options?

I chose this fix because it makes #7088 pass and it reduces surprises.

Get `have_lockfile` helper method actually used.
This change is simple but not easy to explain. What this test does is to
ensure that if bundle install doesn't change anything, then the bundler
version in the lockfile does not get rewritten.

Whereas this test was passing, the implementation was wrong, but two
bugs were "compesating for each other" and making it pass. The
explanation is the following:

Due to a regression in rubygems, in rubygems 3+ "2.0.0.0.a" is
considered higher than "2.0.0.dev". This changes the test because
bundler will never dowgrade the bundler version in a lockfile, so even
if the lockfile gets rewritten, it will still keep "2.0.0.0.a", since
it's considered higher.

However, if we change the test to use "2.0.0.a" instead of "2.0.0.dev",
then the test starts failing and shows the bug in the test.

The bug is that the lock file in the test is written with
"file://localhost" style URLs. However, the lockfile that would be
generated would contain "file://" style URLs. This would trick bundler
into thinking that something has been changed by `bundle install`, so it
will rewrite the lock file, use "2.0.0.dev" as the locked bundler
version, and cause the test to fail.
@deivid-rodriguez deivid-rodriguez changed the title Normalize uris in lockfiles Normalize file URIs in spec's lockfiles Apr 1, 2019
@deivid-rodriguez
Copy link
Member Author

This PR only affects tests, but it's very intricate. I rebased the bug fix in rubygems for one of the issues involved here, and exactly this spec failed when testing against master. Seeing that failure can help understanding the bug in this test.

@hsbt
Copy link
Member

hsbt commented Apr 2, 2019

👍 After merging this, I'm going to rebase #7088

@hsbt
Copy link
Member

hsbt commented Apr 2, 2019

@bundlerbot r+

ghost pushed a commit that referenced this pull request Apr 2, 2019
7089: Normalize file URIs in spec's lockfiles r=hsbt a=deivid-rodriguez

### What was the end-user problem that led to this PR?

The problem was that bumping bundler's version in #7088 made a lockfile spec fail.

### What was your diagnosis of the problem?

My diagnosis was that there was a combination of bugs that was making this spec pass, but the spec was incorrect.

### What is your fix for the problem, implemented in this PR?

My fix is to change the test version the spec uses to not hit rubygems/rubygems#2595, and thus reproduce the failure. And then fix the spec that was incorrect because the lockfile written had different URLs (`file://localhost/<stuff>`) from the lockfile we were checking against (`file://<stuff>`), thus tricking `bundle install` into thinking something had changed, and thus making it rewrite it with an incorrect bundler version.

### Why did you choose this fix out of the possible options?

I chose this fix because it makes #7088 pass and it reduces surprises.


Co-authored-by: David Rodríguez <[email protected]>
@ghost
Copy link

ghost commented Apr 2, 2019

Build succeeded

@ghost ghost merged commit 5f7f860 into master Apr 2, 2019
@ghost ghost deleted the normalize_uris_in_lockfiles branch April 2, 2019 10:20
colby-swandale pushed a commit that referenced this pull request Apr 8, 2019
7089: Normalize file URIs in spec's lockfiles r=hsbt a=deivid-rodriguez

### What was the end-user problem that led to this PR?

The problem was that bumping bundler's version in #7088 made a lockfile spec fail.

### What was your diagnosis of the problem?

My diagnosis was that there was a combination of bugs that was making this spec pass, but the spec was incorrect.

### What is your fix for the problem, implemented in this PR?

My fix is to change the test version the spec uses to not hit rubygems/rubygems#2595, and thus reproduce the failure. And then fix the spec that was incorrect because the lockfile written had different URLs (`file://localhost/<stuff>`) from the lockfile we were checking against (`file://<stuff>`), thus tricking `bundle install` into thinking something had changed, and thus making it rewrite it with an incorrect bundler version.

### Why did you choose this fix out of the possible options?

I chose this fix because it makes #7088 pass and it reduces surprises.


Co-authored-by: David Rodríguez <[email protected]>
(cherry picked from commit 4cae424)
colby-swandale added a commit that referenced this pull request Jun 13, 2019
* 2-0-stable: (89 commits)
  fix changelog 2.0.2 typos
  add v2.0.2 changelog
  bump version to 2.0.2
  Merge #7199
  fix bug where bundler v3 is running a test for bundflet 2
  Merge #6798
  add bors configuation
  port GemHelper from master
  Merge #7080
  Merge #7089
  Merge #7068
  Merge #7036
  Merge #7067
  change Bundler 3 specs in travis to use RubyGems 3.0.3
  bump RubyGems v3 to the latest version on Travis
  Merge #6963
  Merge #7078
  Merge pull request #7061 from bundler/fix_circular_requires
  Merge #6864
  remove linting step in travis (it will still run in each build)
  ...
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants