| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7223: RUBY_ENGINE should always be defined after 1.8.7 r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we have code checking that `RUBY_ENGINE` everytime it's used and I think it's unnecessary.
### What was your diagnosis of the problem?
My diagnosis was that every ruby implementation newer than 1.8 should define this.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the unnecessary code.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7221: Bump rubygems in CI to 3.0.4 and 2.7.10 r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we should make sure everything is ok with the most recent rubygems releases.
### What is your fix for the problem, implemented in this PR?
My fix is to upgrade the rubygems versions in our CI.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7209: Add a minimum ruby version to the generated gemspec r=hsbt a=deivid-rodriguez
This PR is a finished version of #4397.
### What was the end-user problem that led to this PR?
The problem was that the generated gemspec for new gems does not impose a minimum ruby version.
### What is your fix for the problem, implemented in this PR?
My fix is to set the minimum ruby version in the generated gemspec to the minimum ruby version supported by bundler itself.
### Why did you choose this fix out of the possible options?
I chose this fix because it's simple.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
Co-authored-by: Miklos Fazekas <mfazekas@szemafor.com>
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7161: Fix file URIs on Windows r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that file:// URIs were not properly handled on Windows, and those are heavily used by our specs.
### What was your diagnosis of the problem?
My diagnosis was that Windows paths do not start with a slash, so we need to add an extra slash to
separate the host from the path in file:// urls. Otherwise "D:" is parsed as the host segment in the URI.
As a consequence of that change, we also need to strip that leading character when using the path segment for those URIs, so that it's a valid file path on Windows.
This change reduces Windows CI spec failures from 429 to 355.
In order to apply this fix for all file URI's in tests, I extracted a helper method and searched and replaced all file:// ocurrences with the method. The diff is big because of that, but I think it works fine.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Windows paths do not start with a slash, so we add an extra slash to
separate the host from the path in file:// urls. Otherwise "D:" is
parsed as the host segment in the URI.
The path for those URLs now starts with "/", so we ignore that leading
character when using the URI's path.
This reduces Windows CI spec failures from 429 to 355.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7216: Revert "Migrate requires from exe/ to also be relative" r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that in https://github.com/bundler/bundler/pull/7193, I included [a commit](https://github.com/bundler/bundler/pull/7193/commits/d9d2bf6d522dd36d1ef2732e87cef8b7cba729fd) to migrate requires included in bundler's executable to use `require_relative`. That broke stuff.
### What was your diagnosis of the problem?
My diagnosis was the assumption that if `<install_folder>/exe/bundle` lives on a folder, the corresponding bundler lib lives on `<install_folder>/lib` doesn't hold for default gems. Default gems for gems with executables live in `site_lib` but install their executables in the standard gem location. That means that the reference commit breaks bundler when it is installed as a default gem.
### What is your fix for the problem, implemented in this PR?
My fix is to revert the commit.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the easiest way. The proper long term fix is probably to make default gems behave in a more standard way. There's some ongoing work on that here: https://github.com/rubygems/rubygems/pull/2166.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | | |
| | | |
| | | | |
This reverts commit d9d2bf6d522dd36d1ef2732e87cef8b7cba729fd.
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7213: Replace `bundler_2:install` task with `bundler_3:install` r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that the `bundler_2:install` task is no longer meaningful.
### What was your diagnosis of the problem?
My diagnosis was that master points to 2.x now, so this task is useless.
### What is your fix for the problem, implemented in this PR?
My fix is move it to `bundler_3:install`.
### Why did you choose this fix out of the possible options?
I chose this fix because it keeps the shortcut, but for a useful future version.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7217: Fix a typo on a spec comment r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was there's a typo on a comment.
### What was your diagnosis of the problem?
My diagnosis was that typos are bad because they difficult reading and distract devs.
### What is your fix for the problem, implemented in this PR?
My fix is to spell bundler properly.
### Why did you choose this fix out of the possible options?
I chose this fix because `bundler` is the only word that makes sense in the context :)
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7218: Bump rubocop to 0.71 r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that [our build broke](https://travis-ci.org/bundler/bundler/jobs/548144536) due to a dependency incompatibility caused by a new release of `rubocop-performance`.
### What was your diagnosis of the problem?
My diagnosis was that our requirements were very loose for `rubocop-performance`, but very strict for `rubocop`, so very likely to break on `rubocop-performance` releases.
### What is your fix for the problem, implemented in this PR?
My fix is to upgrade `rubocop` to fix the current issue, and to lock `rubocop-performance` so it doesn't happen again in the future.
### Why did you choose this fix out of the possible options?
I chose this fix because it works now and in the future.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| |/ / / |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7214: Fix typo in 2.0.2 release date (changelog) r=hsbt a=semaperepelitsa
Should be June, not May.
https://rubygems.org/gems/bundler/versions/2.0.2
Co-authored-by: Simon Perepelitsa <sema@sema.in>
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7211: Use real paths for `bundle clean` r=colby-swandale a=deivid-rodriguez
Fixes #7208.
### What was the end-user problem that led to this PR?
The problem was that since rubygems 3.0, `bundle clean` incorrectly cleans git gems when they are installed to a symlinked location, but still being used.
### What was your diagnosis of the problem?
My diagnosis was that since https://github.com/rubygems/rubygems/pull/2352, `Gem.dir` returns an array of realpaths, not symlinked ones. However, we don't do the same resolution on the `bundler` side, so in this situation git gems are not correctly skipped from the cleanup.
### What is your fix for the problem, implemented in this PR?
My fix is to resolve the array of paths `bundle clean` uses to do its thing into an array of real paths, just like rubygems does now.
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the problem.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|/ / / |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7202: Fix thread leak in compact index specs r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that sometimes CI fails randomly. For example, https://travis-ci.org/bundler/bundler/jobs/544642885.
### What was your diagnosis of the problem?
My diagnosis was that the spec after it was mocking `Worker#stop` and thus preventing the threads to be actually stopped. That leak would after the spec checking for the number of threads.
### What is your fix for the problem, implemented in this PR?
My fix is to also call the original `#stop` method, so that no threads are left behind.
### Why did you choose this fix out of the possible options?
There's an alternative option, which is to completely remove this spec. In my opinion, this spec is checking exactly the same thing as the previous spec (the whole purpose of `Worker#stop` is to stop threads), but in a more brittle way. So I'm tempted to completely kill the spec instead.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|/ /
| |
| |
| |
| |
| | |
This spec was not stopping threads after itself. That would cause the
previous spec in the file (that checks that no threads are left behind)
to fail.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7002: Respect color option when instantiating shells r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some specs have started to fail randomly in several unrelated PRs. See for example, https://travis-ci.org/bundler/bundler/jobs/500322731. Note that currently bundler specs always run in the same order ( :crying_cat_face: ), but enabling or disabling specs can still affect the final set of specs, and thus make this issue manifest.
### What was your diagnosis of the problem?
My diagnosis was that the base thor's shell is being memoized the first time bundler instantiates a shell. That means further instantiations will not respect the "--no-color" option.
### What is your fix for the problem, implemented in this PR?
My fix is to reset the base thor's shell the proper color / non-color one, every time we instantiate a new shell, not only when "--color" is given.
### Why did you choose this fix out of the possible options?
I chose this fix because it felt like a real issue that should be fixed in lib/, and not only with some state resetting hack inside the specs.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| | |
| | |
| | | |
ANSI codes don't work there.
|
| | |
| | |
| | |
| | | |
For consistency.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Thor's base shell will be memoized the first time it is set. So if we
instantiate a no-color shell first, further instantiations of a bundler
shell will be initialized with a no-color shell by default. This is
caused some sources specs to fail, depending on the order they run.
See for example https://travis-ci.org/bundler/bundler/builds/500328994.
What we do to fix it is to reset the shell unless no-color is explicitly
specified. That way, further instantiations will rerun thor's internal
logic to choose the default shell.
|
| | |
| | |
| | |
| | |
| | | |
The builtin thor's color shell already checks this before printing, and
if not a tty, prints just the string without added color codes.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7203: Fix typo r=deivid-rodriguez a=biow0lf
Co-authored-by: Igor Zubkov <igor.zubkov@gmail.com>
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* 2-0-stable: (89 commits)
fix changelog 2.0.2 typos
add v2.0.2 changelog
bump version to 2.0.2
Merge #7199
fix bug where bundler v3 is running a test for bundflet 2
Merge #6798
add bors configuation
port GemHelper from master
Merge #7080
Merge #7089
Merge #7068
Merge #7036
Merge #7067
change Bundler 3 specs in travis to use RubyGems 3.0.3
bump RubyGems v3 to the latest version on Travis
Merge #6963
Merge #7078
Merge pull request #7061 from bundler/fix_circular_requires
Merge #6864
remove linting step in travis (it will still run in each build)
...
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7199: Allow `rake release` to ask for input (3rd take) r=colby-swandale a=deivid-rodriguez
This PR supersedes #7108 and #7005.
It fixes #6854.
### What was the end-user problem that led to this PR?
The problem was that if users has 2FA authentication on their rubygems account, `rake release` doesn't really work at the moment, since it hangs asking for the OTP code, but without letting the user know.
### What was your diagnosis of the problem?
My diagnosis was that we need to allow the `rake release` helper that shells out to `gem push` to read `gem push` output and show it to the user, so that she can introduce the requested information.
### What is your fix for the problem, implemented in this PR?
My fix is inspired by @segiddins's comment in https://github.com/bundler/bundler/issues/6854#issuecomment-450536844. `Kernel#system` works like we would expect in this situation.
### Why did you choose this fix out of the possible options?
I chose this fix because #7108 had a few problems:
* It would update the `sh` helper, which is used in many different places. This was unnecessary since most of the times we shell out to the `gem` CLI we don't need to ask for input, and it also produced a very verbose output in those cases, since everything the `gem` CLI prints to the screen would be printed by the bundler helpers too. This PR does not change the current output, other than for `rake release`.
* It would print _duplicate_ output. This is a `rake release` test using #7108:
```
$ RUBYOPT="-I../bundler/lib" ../bundler/exe/bundle exec rake release
Successfully built RubyGem
Name: rake_release_tester
Version: 0.1.0
File: rake_release_tester-0.1.0.gem
rake_release_tester 0.1.0 built to pkg/rake_release_tester-0.1.0.gem.
v0.1.0
Tag v0.1.0 has already been created.
Pushing gem to https://rubygems.org...
You have enabled multi-factor authentication. Please enter OTP code.
Code: asd
Your OTP code is incorrect. Please check it and retry.
rake aborted!
Pushing gem to https://rubygems.org...
You have enabled multi-factor authentication. Please enter OTP code.
Code: Your OTP code is incorrect. Please check it and retry.
/home/deivid/Code/bundler/lib/bundler/gem_helper.rb:187:in `sh'
/home/deivid/Code/bundler/lib/bundler/gem_helper.rb:109:in `rubygem_push'
/home/deivid/Code/bundler/lib/bundler/gem_helper.rb:70:in `block in install'
/home/deivid/Code/bundler/lib/bundler/cli/exec.rb:69:in `load'
/home/deivid/Code/bundler/lib/bundler/cli/exec.rb:69:in `kernel_load'
/home/deivid/Code/bundler/lib/bundler/cli/exec.rb:28:in `run'
/home/deivid/Code/bundler/lib/bundler/cli.rb:468:in `exec'
/home/deivid/Code/bundler/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/home/deivid/Code/bundler/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/home/deivid/Code/bundler/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/home/deivid/Code/bundler/lib/bundler/cli.rb:26:in `dispatch'
/home/deivid/Code/bundler/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/home/deivid/Code/bundler/lib/bundler/cli.rb:17:in `start'
../bundler/exe/bundle:30:in `block in <main>'
/home/deivid/Code/bundler/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
../bundler/exe/bundle:22:in `<main>'
Tasks: TOP => release => release:rubygem_push
(See full trace by running task with --trace)
```
This is the same test using this PR:
```
$ RUBYOPT="-I../bundler/lib" ../bundler/exe/bundle exec rake release
rake_release_tester 0.1.0 built to pkg/rake_release_tester-0.1.0.gem.
Tag v0.1.0 has already been created.
Pushing gem to https://rubygems.org...
You have enabled multi-factor authentication. Please enter OTP code.
Code: asdfasdf
Your OTP code is incorrect. Please check it and retry.
```
* Previous approach was hard to test. The test included here might not be great but it's something...
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit cd05f13a74ef2556823be48c23feaf509c3b1de7)
|
| |\ \ \
| | | | |
| | | | | |
Merge #6798 into `2-0-stable`
|
| | | | | |
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
6798: Use https in the Github shortcut by default in Bundler 2 r=colby-swandale a=colby-swandale
This PR is setting Git gems to be fetched over https by default.
Note: This PR is successing #6791
Closes #6785
Co-authored-by: Colby Swandale <me@colby.fyi>
(cherry picked from commit cf45792213fadf97f7aa6464de8ebd79f09725d2)
|
| |\ \ \
| | | | |
| | | | | |
Backport `GemHelper` changes for #7108
|
| | | | | |
|
| |/ / / |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7080: Always pass the `--all` flag when needed r=deivid-rodriguez a=deivid-rodriguez
The problem was that some specs were still using `bundle update` to update all gems, which is deprecated.
My fix is to update all specs to use the new preferred command, namely, `bundle update --all`.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
(cherry picked from commit 63cc70aa2573345ebfb6bddaeef0b9d465591dd9)
(cherry picked from commit e423c83f1f6bccbfc992bca7aef2ad31d6449d75)
|