| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Use the preferred `bundle cache` everywhere, but leave package as an
alias.
Remove duplicated tests.
|
|
|
|
|
| |
So that the behavior is the same regardless of the tested bundler
version.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The simulation is not very friendly because it needs to happen before
`hax.rb` is loaded so, for example, it won't be applied to the lockfile
platforms.
|
|
|
|
| |
This is already short-circuit by rubygems' bundler version finder.
|
| |
|
|
|
|
|
| |
This is essentially the same as "errors if the current is a major
version older than lockfile's bundler version".
|
| |
|
| |
|
|
|
|
|
|
| |
* Drop bundler 1 stuff from tests.
* Move all feature flags to bundler 3 (like they are in 2-0-stable) and
get them tested.
|
|
|
|
| |
And fix specs.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 https://github.com/rubygems/rubygems/issues/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 <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
| |
The `lockfile_uses_separate_rubygems_sources` was causing a lockfile
incompatibility but in my opinion, this incompatibility is not necessary
in the general case.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6971: Fix warning message about bundler version r=colby-swandale a=deivid-rodriguez
Fixes #6909.
### What was the end-user problem that led to this PR?
The problem was that we're recommending a command to make a warning go away that doesn't really make the warning go away.
### What was your diagnosis of the problem?
My diagnosis was that the current recommendation installs the latest bundler, which might not be the same as the version the lock file was created with. If it's not the same, the warning will not go away.
### What is your fix for the problem, implemented in this PR?
My fix is to recommend installing exactly the version the lockfile was created with.
### Why did you choose this fix out of the possible options?
I chose this fix because it's really simple and it should work.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| |
| |
| |
| | |
To actually make the warning go away, we need to recommend exactly
installing the locked version. Otherwise the latest version gets
installed, but not used to being a different major than the one locked,
so the warning stays.
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Ruby 2.6.
|
| |
|
|
|
|
|
| |
It's introduced by URI::Generic channges.
https://github.com/ruby/ruby/commit/ed48bfa5e8770a345424abd7f24f94ea9bbf5973
|
| |
|
| |
|
|
|
|
|
|
| |
# Conflicts:
# spec/install/bundler_spec.rb
# spec/other/compatibility_guard_spec.rb
|
| |
|
|
|
|
| |
Also ensure the resolver processes specs in the correct order for error messages
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|