| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Since it's not TravisCI specific.
|
| |
|
|
| |
To how it's done in other places in the Rakefile
|
| |
|
|
| |
That includes the packages needed by bundler specs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6985: Remove git subshelling from gemspec r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The initial problem was that the default bundler gemspec integrated in ruby-core was shipped nearly empty: https://bugs.ruby-lang.org/issues/15582. That caused issues in bundler: https://github.com/bundler/bundler/issues/6937
### What was your diagnosis of the problem?
I looked into ruby-core history, and still not fully sure how it happened but something I noticed is that bundler does not make this integration easy because ruby-core doesn't have a git environment available, so it needs to do a bit of juggling: https://github.com/ruby/ruby/blob/trunk/tool/rbinstall.rb#L802-L803. We could make things easier.
### What is your fix for the problem, implemented in this PR?
My fix is to stop subshelling to `git` from our own gemspec. I think we do this in the default generated gemspec so that newbie users don't accidentally ship generated files with their gems (although the current solution would still ship generated files that newbie users accidentally commit to source control :smile:). But we shouldn't consider ourselves newbies, so I think we can avoid that.
### Why did you choose this fix out of the possible options?
I chose this fix because it avoids shelling out to git inside the gemspec while still keeping some assurances about the correctness of the shipped set of files through a quality spec.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7009: Rubocop disabled by default r=colby-swandale a=deivid-rodriguez
Closes #7003.
### What was the end-user problem that led to this PR?
The problem was that the current rubocop config gets in the middle too much for my taste.
### What was your diagnosis of the problem?
My diagnosis was that we should enable one cop at a time instead of maintaining a hard too maintain, easily falling out of date `.rubocop_todo.yml` config.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the TODO file, and only keep enabled the cops that current have 0 offenses. We can progressively globally enable more cops as we see fit in the future.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows us to enforce _full_ consistency for specific rules, without getting in the middle at all otherwise.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |/
| |
| |
| |
| |
| |
| | |
We keep the same set of rules that were previously enabled, but make
sure that we don't need to maintain a TODO file with exceptions, and
that upgrading rubocop doesn't silently include new rules without us
explicitly opting in.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7025: Bump rubygems in CI r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was not testing against the latest and greatest rubygems.
### What was your diagnosis of the problem?
My diagnosis was rubygems is outdated since the latest security releases.
### What is your fix for the problem, implemented in this PR?
My fix is to update the tested rubygems.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the only fix.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7024: Remove old 1.8.7 remanents r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we have some really legacy code in our specs.
### What was your diagnosis of the problem?
My diagnosis was that we forgot to remove/update these bits when dropping support.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the legacy code.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the only fix, really.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6728: Fallback to sequentially fetching specs on 429s r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem is that sometimes `bundler` is unable to resolve certain gemfiles. Specifically, sometimes it does not respect the `required_ruby_version` setting. This causes some people to assume that `bundler` will always try to install the latest version of any dependency, regardless of the ruby version being run, because as a matter of fact, this feature sometimes just doesn't work. See for example the discussion at https://github.com/rspec/rspec/issues/25.
The problem was consistently reproducible until a few minutes ago with the following `Gemfile` under `ruby 2.3.7`
```ruby
source "https://rubygems.org"
ruby "2.3.7"
gem "berkshelf", "= 6.3.1"
```
```
$ docker run -it --rm --volume $(pwd):/app ruby:2.3.7 sh -c "cd /app && rm -f Gemfile.lock && bundle install"
Fetching gem metadata from https://rubygems.org/.............
Fetching gem metadata from https://rubygems.org/..
Resolving dependencies....
Fetching public_suffix 3.0.3
Installing public_suffix 3.0.3
Fetching addressable 2.5.2
Installing addressable 2.5.2
Fetching buff-extensions 2.0.0
Installing buff-extensions 2.0.0
Fetching hashie 3.6.0
Installing hashie 3.6.0
Fetching varia_model 0.6.0
Installing varia_model 0.6.0
Fetching buff-config 2.0.0
Installing buff-config 2.0.0
Using bundler 1.16.5
Fetching fuzzyurl 0.9.0
Installing fuzzyurl 0.9.0
Fetching tomlrb 1.2.7
Installing tomlrb 1.2.7
Fetching mixlib-config 2.2.13
Installing mixlib-config 2.2.13
Fetching mixlib-shellout 2.4.0
Installing mixlib-shellout 2.4.0
Fetching chef-config 14.5.33
Installing chef-config 14.5.33
Fetching libyajl2 1.2.0
Installing libyajl2 1.2.0 with native extensions
Fetching ffi-yajl 2.3.1
Installing ffi-yajl 2.3.1 with native extensions
Fetching mixlib-log 2.0.4
Installing mixlib-log 2.0.4
Fetching rack 2.0.5
Installing rack 2.0.5
Fetching uuidtools 2.1.5
Installing uuidtools 2.1.5
Fetching chef-zero 14.0.6
Installing chef-zero 14.0.6
Gem::RuntimeRequirementNotMetError: chef-zero requires Ruby version >= 2.4.0. The current ruby version is 2.3.0.
An error occurred while installing chef-zero (14.0.6), and Bundler cannot continue.
Make sure that `gem install chef-zero -v '14.0.6' --source 'https://rubygems.org/'` succeeds before bundling.
In Gemfile:
berkshelf was resolved to 6.3.1, which depends on
chef was resolved to 14.5.33, which depends on
chef-zero
```
Funny enough, I can no longer reproduce it at the moment, I guess it depends on the specific load conditions of the rubygems.org servers?
### What was your diagnosis of the problem?
My diagnosis was that sometimes our resolution falls back to the old dependency API that didn't implement the `required_ruby_version` setting. In particular, this happens because the new API returns `Net::HTTPTooManyRequests`, so `bundler` gives up and defaults to the old API.
### What is your fix for the problem, implemented in this PR?
My fix is to, instead of directly fall back to the old API when rate limiting happens, try first to fetch the dependencies sequentially instead of in parallel still from the new API, so that rate limit does not affect us.
### Why did you choose this fix out of the possible options?
I chose this fix because it was the only idea that came up. As a matter of fact, #6471 and #6639 were closed because there was nothing we could do, so it seems like it's the only idea so far :)
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| |/ /
| |
| |
| |
| | |
If the compact index returns TooManyRequests, take it easier by
requesting dependencies sequentially instead.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7020: Fix typo r=colby-swandale a=andrew
Co-authored-by: Andrew Nesbitt <andrewnez@gmail.com>
|
| |/ / |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6994: skip colorize examples when the environment was mswin or non tty. r=hsbt a=hsbt
### What was the end-user problem that led to this PR?
Fixes https://github.com/bundler/bundler/issues/6900
### What was your diagnosis of the problem?
The current bundler examples were not supported on mswin and non-tty environments.
### What is your fix for the problem, implemented in this PR?
I make to skip them when Thor detected unsupported environment.
### Why did you choose this fix out of the possible options?
Thor is vendoered now. It's easy to fix bundler's example directly.
Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7016: Fix offenses for more cops r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that a few cops with exceptions in the TODO file have been bothering me recently when moving files around.
### What was your diagnosis of the problem?
My diagnosis was that we can just fix these offenses once and for all, or alternatively disable them inline, or moving them to the permanent config.
### What is your fix for the problem, implemented in this PR?
My fix is to:
* Auto-correct a few simple cops.
* Permanently disable `Style/GuardClause`, because I don't think it always leads to better code, and sometimes it forces artificial refactorings when making changes to methods, making the intention of the changes more obscure.
* Move `rescue Exception` disabling inline, so that when moving that code around, rubocop doesn't complain.
### Why did you choose this fix out of the possible options?
I chose this fix because this is my opinionated approach to this. :)
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | | |
Sometimes rubocop misunderstand semantics, and forces you to write code
that feels worse. I prefer to disable it.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7012: Adapt helper path regex to also work with Windows paths r=deivid-rodriguez a=janpio
### What was the end-user problem that led to this PR?
Some tests were failing on Windows with strange paths not existing.
### What was your diagnosis of the problem?
Turns out a regex in the helper for paths didn't fire on Windows paths as they start with something like `C:/`.
### What is your fix for the problem, implemented in this PR?
So I adapted the regex to also match Windows paths.
### Why did you choose this fix out of the possible options?
... which seemed like the right thing to do here.
---
Fixes 21 test failures on Windows.
closes #6892
Co-authored-by: Jan Piotrowski <piotrowski+git@gmail.com>
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | | |
Co-Authored-By: janpio <piotrowski+github@gmail.com>
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7011: Do not prepend ENV vars for sys_exec calls, but use env param of Open3.popen3 r=deivid-rodriguez a=janpio
### What was the end-user problem that led to this PR?
Several tests were failing on Windows because of the same problem:
### What was your diagnosis of the problem?
On macOS and Linux you can prepend `ENV_VAR=value` in front of a command to set an environment variable for just this command execution.
On Windows this construct doesn't exit and such a command fails.
### What is your fix for the problem, implemented in this PR?
`Open3.popen3`, the method used to executed the command in `sys_exec`, also has an optional `env` parameter which you can use to supply a hash of environment variables. Instead of prepending on the command itself, the code now uses that parameter for the env variables. (Suggested by @deivid-rodriguez in https://github.com/bundler/bundler/issues/6886#issuecomment-452010623).
### Why did you choose this fix out of the possible options?
The parameter of `Open3.popen3` perfectly matches our use case.
---
Fixes 35 failing tests on Windows.
closes #6886
Co-authored-by: Jan Piotrowski <piotrowski+git@gmail.com>
|
| | | | | |
|
| | | | | |
|
| | |/ / |
|
