| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
spec/bundler/bundler_spec.rb:251:25: C: Style/NumericLiteralPrefix: Use 0o for octal literals.
FileUtils.chmod(0400, "tmp/vendor/bundle/unwritable.txt")
^^^^
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
In normal case, all elements in `files` are writable.
So all elements in `files` are scanned.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
lib/bundler.rb:372:120: C: Style/StringLiteralsInInterpolation: Prefer double-quoted strings inside interpolations.
Bundler.ui.warn "Following files may not be writable, so sudo is needed: #{unwritable_files.map(&:to_s).join(',')}"
^^^
|
| | | | |
| | | |
| | | |
| | | | |
This is useful for non-interactive installation with bundler.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
6706: Clean up some specs r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some specs could be more readable and clean.
### What was your diagnosis of the problem?
My diagnosis was that some stuff could be more explicit, some TODO's could be removed because they're already fixed, and there should not be typos.
### What is your fix for the problem, implemented in this PR?
My fix is to make the obvious changes to fix what I diagnosed.
### Why did you choose this fix out of the possible options?
I chose this fix because it makes the specs clear, in my opinion.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
