| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
For consistency with `spec_dir`.
|
| |
|
| |
|
|
|
|
|
| |
Instead, make sure we always load the local copy of bundler during
specs, and never end up using the default copy.
|
| |
|
| |
|
| |
|
|
|
|
| |
Don't think it will make a difference, but I'll try.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
If the compact index returns TooManyRequests, take it easier by
requesting dependencies sequentially instead.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Fixes issues when gems get yanked, which leads to the cached infos being longer than what is on the server.
Being longer, the compact index api just return a 416, and bundler would fallback to the dependency API.
Retrying to the compact index with no range would fix the issue. This is what this fix does.
|
| |
|
| |
|
|
|
|
|
| |
this test appears to only fail when the server is rubygems.org, so I
moved the test into realworld and pulled in vcr.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Ruby core needs to change `Spec::Path.root` and gemspec, bin, spec
directories structure.
* Added Spec::Path.bin, gemspec, spec methods.
* Replace Spec::Path methods from relative references like "../../..".
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Avoid Range Not Satisfiable errors during normal request flow
### What was the end-user problem that led to this PR?
Previously, Bundler was requesting partial response ranges for the Rubygems compact index that could be empty. Since Rubygems was [ignoring the `ETag` header](https://github.com/rubygems/rubygems.org/pull/1652) for these requests, empty ranges would occur whenever the versions index (for instance) hadn't been modified since the version Bundler currently had cached. When this happened, Rubygems would respond with a 416 (Range Not Satisfiable). Bundler would treat this as a `Bundler::HTTPError`, and fall back to using `Fetcher::Dependency` for dependency info. Sadly, that meant metadata about what Ruby version each dependency required was no-longer checked, and updates for gems which should be limited by the system Ruby version were failing.
Closes #5373.
### What was your diagnosis of the problem?
See above
### What is your fix for the problem, implemented in this PR?
This PR updates the range Bundler requests from Rubygems to ensure it's always satisfiable. It does that but requesting all bytes from (and including) the final byte in the Bundler cache, rather than all bytes after (and not including) it.
### Why did you choose this fix out of the possible options?
An alternative fix would be to catch the 416 responses and retry the index lookup in those cases, asking for a full response. That would mean an extra request in all of those cases, though - this method keeps the number of calls to Rubygems down.
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=segiddins
remove forbidden chars in cassettes pathname
### What was the end-user problem that led to this PR?
Users running Micorsoft Windows are currently unable to clone to Bundler project due to a forbidden character in the folder path:
`spec/support/artifice/vcr_cassettes/realworld/api.rubygems.org/api/v1/dependencies?gems=bundler'`
The `?` being the forbidden character.
See #5828
### What is your fix for the problem, implemented in this PR?
Replaced the forbidden character in the folder name with a `-` and updated the VCR spec helper to replace any forbidden character with a `-` in the filename function.
### Why did you choose this fix out of the possible options?
This was the most simple approach to fix the issue.
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[2.0] Remove RubyGems Aggregate & support transitive source pinning
### What was the end-user problem that led to this PR?
The problem was that the resolver could resolve specs from _any_ of the sources specified in the Gemfile, even if that source had nothing to do with the spec in question. This was such a large security vulnerability that, when discovered, it warranted a CVE and its own minor release of Bundler.
Closes #3671.
Closes #3696.
Closes #4059.
### Was was your diagnosis of the problem?
My diagnosis was that we needed to get rid of the notion of a `rubygems aggregate` and enforce that specs could only come either from the source they were declared to come from (the top-level source if declared at the top-level of the Gemfile, else a scoped source), or a source that it transitively "inherited" from the gems that required it.
### What is your fix for the problem, implemented in this PR?
My fix is to disable multiple top-level sources in the Gemfile, remove the RubyGems aggregate, and filter the sources gems could come from as described above.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows doing the filtering in a reasonably performant manner, and refactors the way we handle sources to abstract some of the grossness in such a way that the machinations to make sure that all of the necessary gem info is downloaded is encapsulated into a single method, driven from the definition, rather than being specific to rubygems sources.
See https://github.com/bundler/bundler/pull/4714 and https://github.com/bundler/bundler/pull/4930 for the prior implementation.
|
| |/ |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
content-length headers
|
| |
|
| |
|
|
|
|
| |
Run `rubocop -a --only Style/PercentLiteralDelimiters` and `rubocop --auto-gen-config`.
|
| |
|