| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6733: Check for file or folder when checking for git hash in build metadata r=colby-swandale a=colby-swandale
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
A change that was introduced in #6664 is breaking RubyGem's specs because the Build Metadata is not being generated correctly.
This is breaking because the change is checking for the `.git` to determine if the git hash should be fetched for the version string. This folder does not exist in the submodule in RubyGems' repo
### What was your diagnosis of the problem?
See https://travis-ci.org/rubygems/rubygems/jobs/437576972
### What is your fix for the problem, implemented in this PR?
Check if `.git` exists either as a file or folder
Co-authored-by: Colby Swandale <me@colby.fyi>
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6719: Update for new bors merge commit message r=colby-swandale a=segiddins
### What was the end-user problem that led to this PR?
The problem was andre updated @bundlerbot and it makes merges with a new message now
### What was your diagnosis of the problem?
My diagnosis was the merge message had changed
### What is your fix for the problem, implemented in this PR?
My fix update a regexp or two
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* 1-16-stable:
Version 1.16.6 with changelog
fix uninitialized @use_gvp instance var warning
no longer test Ruby 1.9.3 against rubygems master
Merge #6708
Auto merge of #6697 - walf443:added_changelog_section, r=hsbt
Merge #6687
Merge #6686
Auto merge of #6670 - bundler:colby/invite-stephanie-morillo, r=segiddins
Auto merge of #6627 - agrim123:agr-fix-add-groups, r=deivid-rodriguez
Auto merge of #6612 - hdf1986:readme-bundle-add, r=segiddins
Auto merge of #6495 - bundler:segiddins/6491-extra-gem-platform-in-lockfile, r=segiddins
Auto merge of #6493 - agrim123:agr-update-bundle-update-docs, r=colby-swandale
Auto merge of #6310 - utilum:rescue_unspecified_exception, r=segiddins
Auto merge of #6184 - arbonap:pa-check-in-gemfile-docs, r=indirect
fix typo
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6708: Fix only_update_to_newer_versions regression r=greysteil a=theflow
This is my attempt to fix #6529
### What was the end-user problem that led to this PR?
Running `bundle update` with `BUNDLE_ONLY_UPDATE_TO_NEWER_VERSIONS: "true"` resulted in a gem getting downgraded to a really old version in a certain edge case. Ironically it wouldn't get downgraded when `BUNDLE_ONLY_UPDATE_TO_NEWER_VERSIONS` was set to false.
### What was your diagnosis of the problem?
My diagnosis was that https://github.com/bundler/bundler/commit/47256d20cb05ebc724ee67173094682153b6b4aa tried to solve the problem of still allowing manual downgrades in the Gemfile while `only_update_to_newer_versions` is true. But introduced a regression that prevented the `additional_base_requirements_for_resolve` method to work as intended:
This is the relevant change from that commit that tries to avoid adding the `>=` requirement if the requirement in the Gemfile is different than the requirement in the lockfile (as far as I understand it):
```ruby
next requirements if @locked_deps[name] != dependencies_by_name[name]
```
I identified two problems
1. `dependencies_by_name[name]` returns an array of `Bundler::Dependency`, where as
`@locked_deps[name]` just returns a single `Bundler::Dependency`. Comparing the two will always be false.
1. `@locked_deps` is always empty in case of `bundle update`. See: https://github.com/bundler/bundler/blob/3d9e6167a7df9ca89a030dfe95c7cdff293e74a9/lib/bundler/definition.rb#L95
### What is your fix for the problem, implemented in this PR?
My fixes:
1. Make sure `dependencies_by_name` is a hash with `Bundler::Dependency` as values
1. Fetch the `@locked_gems.dependencies` again instead of using `@locked_deps`
1. The existing test worked for me with and without the `only_update_to_newer_versions` set to true, I replaced it with a reproduction of the edge case I was investigating (this is as minimal as I could make it)
1. I've added a test for the manual downgrading case.
### Why did you choose this fix out of the possible options?
This is the only way I could make these cases work. It's possible there are other edge cases I don't understand.
Co-authored-by: Florian Munz <surf@theflow.de>
(cherry picked from commit 8501b1e3608579acf53a4978b62c0d8891d23005)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[CLI::GEM] bundle gem will generate homepage_uri and code and changelog section …
### What was the end-user problem that led to this PR?
The problem was I always have to remember how to add CHANGELOG.md when I set up a new gem.
### What was your diagnosis of the problem?
My diagnosis was that CHANGELOG.md has become enough of a community standard that it makes sense to offer it in bundle gem.
### What is your fix for the problem, implemented in this PR?
My fix is only added metadata[:changelog_uri] to generated gemspec file.
Changelog.md file is not generated by default.
### Why did you choose this fix out of the possible options?
I chose this fix because Changelog.md file format is different by projects.
(cherry picked from commit c7ed6a2cda1963da6b1cdd0bfcffd8616527a9aa)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6687: Fix assignment in condition. r=colby-swandale a=voxik
I am not sure what is the purpose of this code neither I have idea if the proposed fix is actually correct, but I am quite sure that the condition does not make sense, because the assignment takes priority and therefore the branch is never accessible. So I just take a guess and submitted this PR to open the discussion ;)
Please note this was pointed out by Coverity scan of the Bundler code:
~~~
Error: DEADCODE (CWE-561):
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: cond_return: Condition "nil && Bundler.rubygems().loaded_specs("bundler")", returning "nil". Now the type of "nil && Bundler.rubygems().loaded_specs("bundler")" must be null.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: assignment: Assigning: "loaded_spec" = "nil && Bundler.rubygems().loaded_specs("bundler")".
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: possible_types: At condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))", the type of "loaded_spec" must be null.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: implied_false: "nil" implies that the truth value of "nil" must be false.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: cond_return: Condition "nil && Bundler.rubygems().loaded_specs("bundler")", returning "nil". The truth value of "nil && Bundler.rubygems().loaded_specs("bundler")" must be false.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: truth: At condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))", the truth value of "loaded_spec" must be false.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: dead_error_condition: The condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))" cannot be true.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: dead_error_line: Execution cannot reach the expression "idx << loaded_spec" inside this statement: "(loaded_spec = (nil && Bund...".
# 20| s.loaded_from = File.expand_path("..", __FILE__)
# 21| end
# 22|-> if loaded_spec = nil && Bundler.rubygems.loaded_specs("bundler")
# 23| idx << loaded_spec # this has to come after the fake gemspec, to override it
# 24| elsif local_spec = Bundler.rubygems.find_name("bundler").find {|s| s.version.to_s == VERSION }
~~~
Co-authored-by: Vít Ondruch <vondruch@redhat.com>
(cherry picked from commit 8c080ff6e7c3ce8fdd237f23eb499b197d56954d)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6686: Output OpenSSL information only when OpenSSL is available. r=segiddins a=voxik
It seems that only single OpenSSL availability check should be enough to output or not output the OpenSSL information.
I split this into two commits, so you can cherry-pick, in case you want to be more cautious about the availability of specific constants, but since they were introduced in Ruby 1.8.0 (https://github.com/ruby/ruby/commit/78ff3833fb67c8005a9b851037e7), I would not bother.
Please note that that this code was pointed out by Coverity scanner (although it is definitely not an error):
~~~
Error: FORWARD_NULL (CWE-476):
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/env.rb:113: null_check: Calling "defined?(OpenSSL)" implies that "OpenSSL" might be null-like.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/env.rb:114: property_access: Accessing a property of null-like value "OpenSSL".
# 112| out << [" Bin Dir", Gem.bindir]
# 113| out << ["OpenSSL"] if defined?(OpenSSL)
# 114|-> out << [" Compiled", OpenSSL::OPENSSL_VERSION] if defined?(OpenSSL::OPENSSL_VERSION)
# 115| out << [" Loaded", OpenSSL::OPENSSL_LIBRARY_VERSION] if defined?(OpenSSL::OPENSSL_LIBRARY_VERSION)
# 116| out << [" Cert File", OpenSSL::X509::DEFAULT_CERT_FILE] if defined?(OpenSSL::X509::DEFAULT_CERT_FILE)
~~~
Co-authored-by: Vít Ondruch <vondruch@redhat.com>
(cherry picked from commit 0d7259e69951b5d6f99f4ddd082508d7ef38fce9)
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Add Stephanie Morillo to gemspec author list
(cherry picked from commit 668c06102dbf9843c19c3524fd43c0731d451ffa)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix singular groups on injecting gem
### What was the end-user problem that led to this PR?
The problem was that on adding a gem to a group via
```bash
bundle add rack --group=dev
```
It gets added as
```ruby
gem "rack", :group => [:dev]
```
It should rather be
```ruby
gem "rack", :group => :dev
```
### What was your diagnosis of the problem?
My diagnosis was to not add single groups in the array.
### What is your fix for the problem, implemented in this PR?
My fix was to pick the element from the array of groups and append using
```ruby
":group => :#{d.groups.first}"
```
### Why did you choose this fix out of the possible options?
I chose this fix because it seemed to most appropriate.
(cherry picked from commit 1a10427f9c76ffb29de25fe75d15c950682d01e4)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Updated 'bundle add' to rspec install guide
### What was the end-user problem that led to this PR?
There's a new command `bundle add` which is almost unknown
### What was your diagnosis of the problem?
We are promoting to use a simple append to the Gemfile when there's a `bundle add` command available
### What is your fix for the problem, implemented in this PR?
My fix is just a little readme change :sweat_smile:
### Why did you choose this fix out of the possible options?
Because it's a simple fix and provides more exposure to the command
(cherry picked from commit 34f909fc351934c00a7dcc3e3ea76771fd3f903f)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=segiddins
[Definition] Filter out unneeded gem platforms after resolving
### What was the end-user problem that led to this PR?
The problem was the lockfile would contain platform-specific gems that it didn't need
Closes https://github.com/bundler/bundler/issues/6491
### What was your diagnosis of the problem?
My diagnosis was the resolver sometimes activates platforms it doesn't need, since it can't know it won't need them
### What is your fix for the problem, implemented in this PR?
My fix is to use `SpecSet#for` to filter out gems that won't ever be used
### Why did you choose this fix out of the possible options?
I chose this fix because it isn't re-inventing the wheel!
(cherry picked from commit 7b603f39e32a466cb1a8235a963968b2103e665e)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add documentation for --all flag of bundle update
### What was the end-user problem that led to this PR?
`bundle update` throws an error if run without any flags. `--all` flag was introduced to update all gems instead of no flags. This was not mentioned in docs.
(cherry picked from commit bbd0b49aa2260de17b697a21f2bb932959284c5c)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix some rescue calls that do not specifiy error type.
The problem I noticed was in style, several instances of `rescue` clauses that do not specify an exception type. This is noted in in the Ruby Style Guide as [Avoid rescuing the Exception class](https://github.com/bbatsov/ruby-style-guide#no-blind-rescues).
My diagnosis was that at least some of those are leftover style. They are noted in `.rubocop_todo.yml`. To make sure, I asked on Slack.
My fix is to make as many of them more specific, specifying at least `StandardError`, and trying to be more specific.
No other ways of addressing this came to mind. I'd be happy to consider.
(cherry picked from commit ff6b8712a0337305ba9617e35545b9e8f8cd4a53)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Update docs to reflect revised guidance to check in locks for gems
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
The problem was...
- Bundler stopped gitignoring gem locks. The change was merged in but we need to reflect that change in documentation.
### What was your diagnosis of the problem?
My diagnosis was...
- To add in documentation explaining why Bunder now does _not_ gitignore gem locks.
### What is your fix for the problem, implemented in this PR?
My fix...
- Update the `gemfile.lock` section of `bundle install` man pages as well as the `gemfile` man page.
### Why did you choose this fix out of the possible options?
I chose this fix because...
- This addresses open issue https://github.com/bundler/bundler/issues/5879
(cherry picked from commit 30f7b45e2414eb82e1dcc592a4dd5146438f4a63)
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6718: Correct `bundle show` deprecation r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was `bundle show` deprecation messages are incorrect:
```
$ bundle show yard
[DEPRECATED FOR 2.0] use `bundle list` instead of `bundle show`
Resolving dependencies...
/home/deivid/Code/activeadmin/.bundle/ruby/2.5.0/gems/yard-0.9.16
$ bundle list yard
ERROR: "bundle list" was called with arguments ["yard"]
Usage: "bundle list"
```
### What was your diagnosis of the problem?
My diagnosis was that deprecation messages only mention `bundle list`, but in some cases, the replacement is `bundle info`.
### What is your fix for the problem, implemented in this PR?
My fix is to replace "show" in the original command with the appropriate alternative in each case.
### Why did you choose this fix out of the possible options?
I chose this fix because it was the most user friendly message, since it prints the exact command the user needs to type to get rid of the warning.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
With a single gem, it will be replaced by `bundle info`, not by `bundle
list`.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I don't know why it was there, and it makes things more complicated with
dealing and running assertions on ARGV.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
6711: Avoid fetching an rebuilding git gems when it's not necessary r=segiddins a=casperisfine
Kind of a followup to https://github.com/bundler/bundler/pull/4272
### The issue
As demonstrated by the updated test case, whenever a gem is changed (even a non-git one), bundler re-fetch all git gems, and recompile their extensions (if any).
You can repro that issue by running the modified `git_spec.rb` against master.
### The proposed fix
In that patch I simply make `Source::Git` skip the `fetch` step if the `cached_revision` matches the install path.
Since `install_path` uses only the first 10 characters of the full revision, there is a very very small chance of a collision happening, but It's so small that I think it can be ignored.
However my understanding of the codebase is too limited to be 100% sure the git gem would be properly updated if it's definition (`branch` / `ref` / `etc`) is updated. I tried to write a test case for this but couldn't figure out how to create a repo with multiple revisions. I'll keep digging, but I figured I might as well ask for feedback at this stage.
@segiddins any thoughts on this ? (since you fixed #4272), any pointers on how to better test this?
cc @rafaelfranca @jules2689
Co-authored-by: Jean Boussier <jean.boussier@gmail.com>
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
6721: http:// URLs in the gemspec r=colby-swandale a=amatsuda
### What was the end-user problem that led to this PR?
When the users visit https://rubygems.org/gems/bundler and click the links, or access the gem metadata from scripts e.g. gem-src, we're seeing unneeded redirection from http://... to https://... because both github.com and bundler.io redirects http requests to https.
### What is your fix for the problem, implemented in this PR?
Rewrote all http:// URLs in the gemspec to https://.
Co-authored-by: Akira Matsuda <ronnie@dio.jp>
|
| | | | | | |
|
| |/ / / / |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6687: Fix assignment in condition. r=colby-swandale a=voxik
I am not sure what is the purpose of this code neither I have idea if the proposed fix is actually correct, but I am quite sure that the condition does not make sense, because the assignment takes priority and therefore the branch is never accessible. So I just take a guess and submitted this PR to open the discussion ;)
Please note this was pointed out by Coverity scan of the Bundler code:
~~~
Error: DEADCODE (CWE-561):
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: cond_return: Condition "nil && Bundler.rubygems().loaded_specs("bundler")", returning "nil". Now the type of "nil && Bundler.rubygems().loaded_specs("bundler")" must be null.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: assignment: Assigning: "loaded_spec" = "nil && Bundler.rubygems().loaded_specs("bundler")".
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: possible_types: At condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))", the type of "loaded_spec" must be null.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: implied_false: "nil" implies that the truth value of "nil" must be false.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: cond_return: Condition "nil && Bundler.rubygems().loaded_specs("bundler")", returning "nil". The truth value of "nil && Bundler.rubygems().loaded_specs("bundler")" must be false.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: truth: At condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))", the truth value of "loaded_spec" must be false.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: dead_error_condition: The condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))" cannot be true.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: dead_error_line: Execution cannot reach the expression "idx << loaded_spec" inside this statement: "(loaded_spec = (nil && Bund...".
# 20| s.loaded_from = File.expand_path("..", __FILE__)
# 21| end
# 22|-> if loaded_spec = nil && Bundler.rubygems.loaded_specs("bundler")
# 23| idx << loaded_spec # this has to come after the fake gemspec, to override it
# 24| elsif local_spec = Bundler.rubygems.find_name("bundler").find {|s| s.version.to_s == VERSION }
~~~
Co-authored-by: Vít Ondruch <vondruch@redhat.com>
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6708: Fix only_update_to_newer_versions regression r=greysteil a=theflow
This is my attempt to fix #6529
### What was the end-user problem that led to this PR?
Running `bundle update` with `BUNDLE_ONLY_UPDATE_TO_NEWER_VERSIONS: "true"` resulted in a gem getting downgraded to a really old version in a certain edge case. Ironically it wouldn't get downgraded when `BUNDLE_ONLY_UPDATE_TO_NEWER_VERSIONS` was set to false.
### What was your diagnosis of the problem?
My diagnosis was that https://github.com/bundler/bundler/commit/47256d20cb05ebc724ee67173094682153b6b4aa tried to solve the problem of still allowing manual downgrades in the Gemfile while `only_update_to_newer_versions` is true. But introduced a regression that prevented the `additional_base_requirements_for_resolve` method to work as intended:
This is the relevant change from that commit that tries to avoid adding the `>=` requirement if the requirement in the Gemfile is different than the requirement in the lockfile (as far as I understand it):
```ruby
next requirements if @locked_deps[name] != dependencies_by_name[name]
```
I identified two problems
1. `dependencies_by_name[name]` returns an array of `Bundler::Dependency`, where as
`@locked_deps[name]` just returns a single `Bundler::Dependency`. Comparing the two will always be false.
1. `@locked_deps` is always empty in case of `bundle update`. See: https://github.com/bundler/bundler/blob/3d9e6167a7df9ca89a030dfe95c7cdff293e74a9/lib/bundler/definition.rb#L95
### What is your fix for the problem, implemented in this PR?
My fixes:
1. Make sure `dependencies_by_name` is a hash with `Bundler::Dependency` as values
1. Fetch the `@locked_gems.dependencies` again instead of using `@locked_deps`
1. The existing test worked for me with and without the `only_update_to_newer_versions` set to true, I replaced it with a reproduction of the edge case I was investigating (this is as minimal as I could make it)
1. I've added a test for the manual downgrading case.
### Why did you choose this fix out of the possible options?
This is the only way I could make these cases work. It's possible there are other edge cases I don't understand.
Co-authored-by: Florian Munz <surf@theflow.de>
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6707: Run more assertions in more cases r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
I noticed a couple of places where assertions were being excluded and they shouldn't:
* One was introduced by me in #6702, where the specs added (and some already present) started being tested only on bundler 2.x.
* The other one was introduced in f7414bcb17fe1bd67246021251b5f0527bd6afd1, where one assertion would be run only if a certain env variable was not set. I think it was because of a TravisCI environmental issue that now seems fixed.
### What was your diagnosis of the problem?
My diagnosis was that none of these exclusions are necessary.
### What is your fix for the problem, implemented in this PR?
My fix is to restore the excluded assertions to all environments and branches.
### Why did you choose this fix out of the possible options?
I chose this fix because it seems best to avoid future problems.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | | |
So they are run on bundler 1.x too.
|
| | | | |
| | | |
| | | |
| | | | |
I think this was a bad fix and it's no longer necessary.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6686: Output OpenSSL information only when OpenSSL is available. r=segiddins a=voxik
It seems that only single OpenSSL availability check should be enough to output or not output the OpenSSL information.
I split this into two commits, so you can cherry-pick, in case you want to be more cautious about the availability of specific constants, but since they were introduced in Ruby 1.8.0 (https://github.com/ruby/ruby/commit/78ff3833fb67c8005a9b851037e7), I would not bother.
Please note that that this code was pointed out by Coverity scanner (although it is definitely not an error):
~~~
Error: FORWARD_NULL (CWE-476):
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/env.rb:113: null_check: Calling "defined?(OpenSSL)" implies that "OpenSSL" might be null-like.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/env.rb:114: property_access: Accessing a property of null-like value "OpenSSL".
# 112| out << [" Bin Dir", Gem.bindir]
# 113| out << ["OpenSSL"] if defined?(OpenSSL)
# 114|-> out << [" Compiled", OpenSSL::OPENSSL_VERSION] if defined?(OpenSSL::OPENSSL_VERSION)
# 115| out << [" Loaded", OpenSSL::OPENSSL_LIBRARY_VERSION] if defined?(OpenSSL::OPENSSL_LIBRARY_VERSION)
# 116| out << [" Cert File", OpenSSL::X509::DEFAULT_CERT_FILE] if defined?(OpenSSL::X509::DEFAULT_CERT_FILE)
~~~
Co-authored-by: Vít Ondruch <vondruch@redhat.com>
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6316: Display reason to require sudo r=colby-swandale a=okkez
This is useful for non-interactive installation with bundler.
### What was the end-user problem that led to this PR?
https://github.com/treasure-data/omnibus-td-agent/issues/166
I could not notice that bundler needs sudo privilege from logs.
So I checked bundler code.
### What was your diagnosis of the problem?
Bundler does not show the reason to need sudo privilege.
### What is your fix for the problem, implemented in this PR?
Display reason to require sudo.
### Why did you choose this fix out of the possible options?
If bundler displays reason to require sudo, we can notice permission problems as soon as possible.
Co-authored-by: Kenji Okimoto <okimoto@clear-code.com>
|
| | | | |
| | | |
| | | |
| | | | |
Because Dir#[] will return unsorted results.
|
| | | | | |
|
| | | | | |
|
