| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have several source priority bug fixes in master that we have never
released because the need the `disable_multisource` setting toggled, and
that will only happen by default in Bundler 3.
The reason for this is that this setting drops support for multiple
global sources in the gemfile, and also enables separate sections for
each rubygems source in the lockfile. We have considered this to be
backwards incompatible, because Gemfiles using multiple global sources
have not even yet got a deprecation warning telling them that they
should change their Gemfile, so we need to do that before dropping
support.
So, as a compromise solution between fixing the issues that
`disable_multisource` fixes, and providing a friendly migration path for
the removal of multiple global sources support, I thought of the
following solution:
* If the Gemfile has multiple top level sources, print a deprecation
message and run in the old mode (disable_multisource = false).
* If the Gemfile doesn't have multiple top level sources, switch
`disable_multisource` to true automatically and run in that mode.
I think this allow us to ship the most secure mode in the most common
case (no multiple top level sources), while still provide a good
migration path in the other case.
This might still break some situations where the old mode used to
resolve and the new mode does not, but it's for the sake of fixing bugs
and being more secure, so I think it's the price to pay.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
In these tests, there are several nested context, so it's not easy to
see which source each dependency comes (or should come) from. This
should make it a bit easier.
|
| |
|
|
|
|
| |
`DeprecatedError` is exactly the exception that `major_deprecation` rises
when the version is past the deprecation horizon. And
`disable_multisource` will be always true in bundler 3.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Otherwise it doesn't make sense.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Because `bundler_2_mode?` is currently true for every supported mode.
|
| |
|
|
| |
To be like the rest of the pending specs in the file.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7245: Commit generated docs to source control r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that generating docs on the fly every time they are needed (tests, release, installation) is complicated and prone to errors. For example, currently the `rubygems-update` gem that takes care of updating rubygems and install the default bundler does not properly include bundler docs. Also, managing the manifest as a mix of generated and source controlled files is complicated too. Finally, ruby-core already keeps man pages as part of its sources, so this would make us follow their lead.
### What is your fix for the problem, implemented in this PR?
My fix is to keep generated man pages source controlled, and add a task to make sure they are always kept in sync with their "source of truth".
### Why did you choose this fix out of the possible options?
I chose this fix because I think it should simplify things for us.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | |
| |
| |
| | |
So that the examples work in currently supported rubies.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This has the benefit that:
* Allows the installation of bundler as a default gem from rubygems to
include man pages.
* Removes the need to build man pages during our tests.
* Makes working with the manifest easier, because we only have source
controlled files, and not a mix of source control and generated files.
To make sure they never fall out of sync, we replace the previous
`man:build` CI task with a `man:check` task that makes sure the
generated man pages are up to date.
|
| | | |
|
| | |
| |
| |
| |
| | |
Since we no longer use `git` to find out the list of files, the comment
is misleading.
|
| |/
|
|
| |
The build task does not generate any files at `lib/bundler/generated`.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
7287: Fix typo in comment: attibutes -> attributes r=hsbt a=ohbarye
Let me skip answering questions in the pull request template since it's obviously just fixing a typo!
Co-authored-by: Masato Ohba <masato.ohba@quipper.com>
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7286: Fix documents to refer to URLs with https r=deivid-rodriguez a=giraffate
### What was the end-user problem that led to this PR?
End-users experience 301 redirect, or unintentionally visit URL with http and may send email.
### What was your diagnosis of the problem?
I noticed the problem when I was reading codes. Following are some examples using curl to explain this problem.
```
curl -I http://slack.bundler.io/
HTTP/1.1 200 OK
Server: Cowboy
Connection: keep-alive
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 3726
Etag: W/"3Shz0DQR5y/DyBrYbyUBAQ=="
Date: Fri, 09 Aug 2019 14:16:23 GMT
Via: 1.1 vegur
```
```
curl -I http://contributor-covenant.org
HTTP/1.1 301 Moved Permanently
Cache-Control: public, max-age=0, must-revalidate
Content-Length: 49
Content-Type: text/plain
Date: Sun, 04 Aug 2019 09:47:02 GMT
Location: https://contributor-covenant.org/
Age: 448201
Connection: keep-alive
Server: Netlify
X-NF-Request-ID: 3de60b71-391e-4a6e-8cd4-74a12f217c80-14980829
```
### What is your fix for the problem, implemented in this PR?
My fix is to replace http URLs with https URLs.
### Why did you choose this fix out of the possible options?
It's because this fix is simple and easy.
Co-authored-by: Takayuki Nakata <f.seasons017@gmail.com>
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7285: Bump rspec dependency to 3.8 r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that tests fail using rspec 3.7 or older.
### What was your diagnosis of the problem?
My diagnosis was that we're using `config.bisect_runner` which is only available from 3.8.
### What is your fix for the problem, implemented in this PR?
My fix is to bump the requirement.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/
|
|
|
| |
Because we're using `config.bisect_runner` which is only available from
3.8.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7283: Fix spec working by chance r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that this particular spec is like a nightmare that keeps on failing whenever we make changes to bundler, and we keep adding workarounds to it.
### What was your diagnosis of the problem?
My diagnosis was that I should investigate closer what's going on with this spec, and fix it in a better way.
### What is your fix for the problem, implemented in this PR?
My fix is to fix several issues with the spec, and to essentially revert it back to the way it looked before https://github.com/bundler/bundler/commit/e63e844bc7444c6a489fcde0dc7011c6c4807edd. See each commit for more details.
### Why did you choose this fix out of the possible options?
I chose this fix because it should make it less painful to keep CI green as we make changes to bundler.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ruby < 2.6"
This reverts commit e63e844bc7444c6a489fcde0dc7011c6c4807edd.
It was introduced to resolve some failing tests at the cost of making
the intention of the spec much less clear.
Thanks to the previous fixes we have added to this spec, we can revert
that patch now.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Previously it was being installed to the :bundle_path
(`/tmp/bundled_app/.bundle`), but the `bundle` helper uses the
`system_gem_path("bin/bundle")`. That means the first `bundle install`in
the spec was actually failing, but not affecting the test status because
of not being called as `bundle!`.
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7280: Improve load path order spec r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was for a while I've had a spec failing locally and that's annoying.
### What was your diagnosis of the problem?
My diagnosis was that if you install a development version of bundler in your system (through `bin/rake install:local`), this spec starts failing with:
```
$ bin/rspec -e "orders the load pa"
Run options: include {:full_description=>/orders\ the\ load\ pa/}
Randomized with seed 55764
Bundler.setup
load order
$ /home/deivid/.rbenv/versions/2.6.3/bin/ruby \
-I/home/deivid/Code/bundler/lib:/home/deivid/Code/bundler/spec -rsupport/hax \
-r/home/deivid/Code/bundler/spec/support/artifice/fail /home/deivid/Code/bundler/exe/bundle \
install --retry 0
Fetching source index from file:///home/deivid/Code/bundler/tmp/gems/remote1/
Resolving dependencies...
Fetching rake 12.3.2
Installing rake 12.3.2
Fetching activesupport 2.3.2
Installing activesupport 2.3.2
Fetching actionmailer 2.3.2
Installing actionmailer 2.3.2
Fetching actionpack 2.3.2
Installing actionpack 2.3.2
Fetching activerecord 2.3.2
Installing activerecord 2.3.2
Fetching activeresource 2.3.2
Installing activeresource 2.3.2
Using bundler 2.1.0.pre.1
Fetching rails 2.3.2
Installing rails 2.3.2
Bundle complete! 1 Gemfile dependency, 8 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
# $? => 0
$ /home/deivid/.rbenv/versions/2.6.3/bin/ruby -I/home/deivid/Code/bundler/lib -e \
<<EOS
require 'rubygems'
require 'bundler'
Bundler.setup
puts $LOAD_PATH
EOS
/home/deivid/Code/bundler/lib
/home/deivid/.rbenv/rbenv.d/exec/gem-rehash
/home/deivid/Code/bundler/tmp/gems/system/gems/rails-2.3.2/lib
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib
/home/deivid/Code/bundler/tmp/gems/system/gems/activeresource-2.3.2/lib
/home/deivid/Code/bundler/tmp/gems/system/gems/activerecord-2.3.2/lib
/home/deivid/Code/bundler/tmp/gems/system/gems/actionpack-2.3.2/lib
/home/deivid/Code/bundler/tmp/gems/system/gems/actionmailer-2.3.2/lib
/home/deivid/Code/bundler/tmp/gems/system/gems/activesupport-2.3.2/lib
/home/deivid/Code/bundler/tmp/gems/system/gems/rake-12.3.2/lib
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/site_ruby/2.6.0
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/site_ruby/2.6.0/x86_64-linux
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/site_ruby
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/vendor_ruby/2.6.0
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/vendor_ruby/2.6.0/x86_64-linux
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/vendor_ruby
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0/x86_64-linux
# $? => 0
$ /home/deivid/.rbenv/versions/2.6.3/bin/ruby -I/home/deivid/Code/bundler/lib -e puts\ \$LOAD_PATH
/home/deivid/Code/bundler/lib
/home/deivid/.rbenv/rbenv.d/exec/gem-rehash
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/site_ruby/2.6.0
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/site_ruby/2.6.0/x86_64-linux
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/site_ruby
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/vendor_ruby/2.6.0
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/vendor_ruby/2.6.0/x86_64-linux
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/vendor_ruby
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0/x86_64-linux
# $? => 0
orders the load path correctly when there are dependencies (FAILED - 1)
Retried examples: 0
Failures:
1) Bundler.setup load order orders the load path correctly when there are dependencies
Failure/Error:
expect(load_path).to start_with(
"/gems/rails-2.3.2/lib",
"/gems/activeresource-2.3.2/lib",
"/gems/activerecord-2.3.2/lib",
"/gems/actionpack-2.3.2/lib",
"/gems/actionmailer-2.3.2/lib",
"/gems/activesupport-2.3.2/lib",
"/gems/rake-12.3.2/lib"
)
expected ["/gems/rails-2.3.2/lib", "/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.....3.2/lib", "/gems/actionmailer-2.3.2/lib", "/gems/activesupport-2.3.2/lib", "/gems/rake-12.3.2/lib"] to start with "/gems/rails-2.3.2/lib", "/gems/activeresource-2.3.2/lib", "/gems/activerecord-2.3.2/lib", "/gems/actionpack-2.3.2/lib", "/gems/actionmailer-2.3.2/lib", "/gems/activesupport-2.3.2/lib", and "/gems/rake-12.3.2/lib"
Commands:
$ /home/deivid/.rbenv/versions/2.6.3/bin/ruby \
-I/home/deivid/Code/bundler/lib:/home/deivid/Code/bundler/spec -rsupport/hax \
-r/home/deivid/Code/bundler/spec/support/artifice/fail /home/deivid/Code/bundler/exe/bundle \
install --retry 0
Fetching source index from file:///home/deivid/Code/bundler/tmp/gems/remote1/
Resolving dependencies...
Fetching rake 12.3.2
Installing rake 12.3.2
Fetching activesupport 2.3.2
Installing activesupport 2.3.2
Fetching actionmailer 2.3.2
Installing actionmailer 2.3.2
Fetching actionpack 2.3.2
Installing actionpack 2.3.2
Fetching activerecord 2.3.2
Installing activerecord 2.3.2
Fetching activeresource 2.3.2
Installing activeresource 2.3.2
Using bundler 2.1.0.pre.1
Fetching rails 2.3.2
Installing rails 2.3.2
Bundle complete! 1 Gemfile dependency, 8 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
# $? => 0
$ /home/deivid/.rbenv/versions/2.6.3/bin/ruby -I/home/deivid/Code/bundler/lib -e \
<<EOS
require 'rubygems'
require 'bundler'
Bundler.setup
puts $LOAD_PATH
EOS
/home/deivid/Code/bundler/lib
/home/deivid/.rbenv/rbenv.d/exec/gem-rehash
/home/deivid/Code/bundler/tmp/gems/system/gems/rails-2.3.2/lib
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib
/home/deivid/Code/bundler/tmp/gems/system/gems/activeresource-2.3.2/lib
/home/deivid/Code/bundler/tmp/gems/system/gems/activerecord-2.3.2/lib
/home/deivid/Code/bundler/tmp/gems/system/gems/actionpack-2.3.2/lib
/home/deivid/Code/bundler/tmp/gems/system/gems/actionmailer-2.3.2/lib
/home/deivid/Code/bundler/tmp/gems/system/gems/activesupport-2.3.2/lib
/home/deivid/Code/bundler/tmp/gems/system/gems/rake-12.3.2/lib
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/site_ruby/2.6.0
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/site_ruby/2.6.0/x86_64-linux
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/site_ruby
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/vendor_ruby/2.6.0
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/vendor_ruby/2.6.0/x86_64-linux
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/vendor_ruby
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0/x86_64-linux
# $? => 0
$ /home/deivid/.rbenv/versions/2.6.3/bin/ruby -I/home/deivid/Code/bundler/lib -e puts\ \$LOAD_PATH
/home/deivid/Code/bundler/lib
/home/deivid/.rbenv/rbenv.d/exec/gem-rehash
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/site_ruby/2.6.0
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/site_ruby/2.6.0/x86_64-linux
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/site_ruby
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/vendor_ruby/2.6.0
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/vendor_ruby/2.6.0/x86_64-linux
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/vendor_ruby
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0
/home/deivid/.rbenv/versions/2.6.3/lib/ruby/2.6.0/x86_64-linux
# $? => 0
# ./spec/runtime/setup_spec.rb:164:in `block (3 levels) in <top (required)>'
# ./spec/spec_helper.rb:127:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:96:in `block (2 levels) in <top (required)>'
# ./spec/support/rubygems_ext.rb:43:in `load'
# ./spec/support/rubygems_ext.rb:43:in `gem_load'
Finished in 0.82951 seconds (files took 1.17 seconds to load)
1 example, 1 failure
Failed examples:
rspec ./spec/runtime/setup_spec.rb:149 # Bundler.setup load order orders the load path correctly when there are dependencies
Randomized with seed 55764
```
This is because the development version of bundler installed gets activated and that messes up the load path assertion.
### What is your fix for the problem, implemented in this PR?
My fix is to build the development bundler gem, install it to `tmp/system` and make sure that version gets activated. And include that in the test assertion.
### Why did you choose this fix out of the possible options?
I chose this fix because it makes the spec independent from the developer's environment.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| |
| |
| |
| |
| | |
Previously, if bundler-2.1.0.pre.1 would be installed globally, it would
fail. Now we force that a locally installed version of bundler is used,
so it always passed regardless of which bundler is installed globally.
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7281: Bump test deps r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some test dependencies, sinatra and rack in particular, were outdated.
### What was your diagnosis of the problem?
My diagnosis was that we should use the latest versions.
### What is your fix for the problem, implemented in this PR?
My fix is to upgrade them. Both of them seem 100% compatible with respect to our test suite because there seems to be now failures, even though there was a note suggesting the opposite.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7277: Rerecord cassettes r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we have not rerecorded cassettes in a while.
### What was your diagnosis of the problem?
My diagnosis was that it's a good practice to rerecord cassettes once in a while.
### What is your fix for the problem, implemented in this PR?
My fix is to rerecord the cassettes.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| |
| |
| | |
Don't think it will make a difference, but I'll try.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7264: Consistent lockfiles r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that when a Gemfile would specify path sources with paths starting with "./", the generated lockfile would be inconsistent on `bundle install` and `bundle update`.
### What was your diagnosis of the problem?
My diagnosis was that when running `bundle update`, the bundle would be unlocked, and bundler would order the path sources according to the path present in the Gemfile ("./aaa" for example). On the other hand, when running `bundle install`, bundler would read the relative paths from the lockfile, where they are normalized ("aaa" for example).
### What is your fix for the problem, implemented in this PR?
My fix is to normalize relative paths when creating the source list, so that "aaa" is always used over "./aaa".
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the problem and it's backwards compatible (as in, it doesn't break any specs that assert for specific lockfiles).
Fixes #7262.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
When Gemfile would specify path sources as relative paths starting with
"./", the lockfile would have inconsistent order on `bundle install` and
`bundle update`.
|
| | | | |
|
| | | | |
|
