| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7190: Remove incorrect `man:clobber` task r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that `man:clobber` was listed under `bin/rake -T` but it wasn't working because it was trying to remove a non existent folder.
### What was your diagnosis of the problem?
My diagnosis was that the correct task is actually `bin/rake man:clean`.
### What is your fix for the problem, implemented in this PR?
My fix is to remove `man:clobber` and move its description on top of `man:clean`, so that it's correctly listed under `bin/rake -T`.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| |
| |
| |
| | |
And move its description on top of the correct task, `man:build`, so
that it appears under `bin/rake -T`.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
7185: Try to help GitHub recognize the MIT license r=hsbt a=indirect
It seems like GitHub can't tell what license this is, despite explicitly
naming it inside the file. These changes make our license file closer to
other license files that GitHub does successfully recognize as MIT.
Hopefully it'll work.
Co-authored-by: Andre Arko <andre@arko.net>
|
| | |
| |
| |
| |
| |
| |
| | |
It seems like GitHub can't tell what license this is, despite explicitly
naming it inside the file. These changes make our license file closer to
other license files that GitHub does successfully recognize as MIT.
Hopefully it'll work.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7188: Second try at azure fix r=deivid-rodriguez a=deivid-rodriguez
This is a followup to #7186.
### What was the end-user problem that led to this PR?
The problem was that Azure CI is still unstable.
### What was your diagnosis of the problem?
My diagnosis was that sometimes MRI 2.4.3 is used, and sometimes MRI 2.4.5 is used instead.
### What is your fix for the problem, implemented in this PR?
My fix, for now, is to make the steps independent from the ruby included in the container that it's run.
### Why did you choose this fix out of the possible options?
I chose this fix because other better fixes require more work and I don't want to spend a lot of time on this at the moment.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | | |
To emphasize that I want `\r` as a literal, but `$ruby_version` evaluated.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
At the moment, some Azure instances use 2.4.5, and others use 2.4.3. No
idea why.
As a solution, I relax the requirement to ">= 2.4", then capture the
exact version we're using, and patch the appropriate readline file
according to that.
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7187: Add debugging information to flaky test r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that last master build failed with a test failure I had never seen: https://travis-ci.org/bundler/bundler/jobs/538089338.
### What was your diagnosis of the problem?
My diagnosis was that this failure _is_ indeed order dependent, since it only appeared after enabling test suite randomization. BUT, this failure is not consistently reproducible.
### What is your fix for the problem, implemented in this PR?
This PR does not fix the problem. It only adds some debugging information, so we have more information to figure this out when it happens again.
### Why did you choose this fix out of the possible options?
I chose this ~fix~ change because it's no clear to me why this happened or how to fix it.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7186: Fix azure CI issue r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that Azure CI is now failing.
### What was your diagnosis of the problem?
My diagnosis was that the ruby version was upgraded, and as a consequence, a hardcoded path in our configuration no longer exists.
### What is your fix for the problem, implemented in this PR?
My fix is to update the path and to be more explicit about the ruby version we want to use, so that this doesn't happen again.
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the problem, and prevents it from happening in the future.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | | |
So azure upgrades never break the hardcoded path to the readline diff we
currently need to apply further down in the configuration.
|
| |/ /
| |
| |
| |
| | |
Ruby version seems to have been updated from 2.4.3 to 2.4.5, so the
hardcoded patch no longer exists.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7179: Random test order r=deivid-rodriguez a=deivid-rodriguez
This is a follow-up to the work started by @colby-swandale in #7103.
### What was the end-user problem that led to this PR?
The problem was that our specs do not run in random order, so the tests might be depending on state set by other tests to pass.
### What was your diagnosis of the problem?
My diagnosis was that we should enable random test ordering.
### What is your fix for the problem, implemented in this PR?
My fix is to randomize the specs and fix the resulting failures.
Co-authored-by: Colby Swandale <me@colby.fyi>
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
RSpec bisector needs to read the configuration, for example to find out
which kind of runner to use. So, it needs to load the spec helper. It
does that, though, before actually shelling out to run any tests. If we
modify the environment at the top level, that changes it before shelling
out and thus we fail to find RSpec in the subsequent subprocess.
So, instead of modifying the environment at the top level, we do it
lazily in the `before(:suite)` hook.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
RSpec warns that the default `:fork` is much faster but it does not
always work. It seems to be the case for us, since bisection seems to
hang there when using that runner.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Sometimes, the initial environment before the first spec would not be
properly reset, causing some specs to fail if they run first.
Reproducible with
```
bin/rspec \
--seed 52285 \
-e "Bundler.unbundled_env behaves like an unbundling helper should clean up RUBYLIB"
```
This change causes a separate spec failure, namely:
```
$ bin/rspec spec/bundler/gem_helper_spec.rb:294
1) Bundler::GemHelper gem management release:rubygem_push success messaging No allowed_push_host set RUBYGEMS_HOST env var is set should report successful push to the host from the environment
Failure/Error: expect(Bundler.ui).to receive(:confirm).with(message)
#<Bundler::UI::Shell:0x0000556bc98a8f60 @shell=#<Bundler::Thor::Shell::Color:0x0000556bc98e80e8 @base=nil, @mute=false, @padding=0, @always_force=false>, @level="info", @warning_history=[]> received :confirm with unexpected arguments
expected: ("Pushed lorem__ipsum 0.1.0 to https://custom.env.gemhost.com")
got: ("Pushed lorem__ipsum 0.1.0 to rubygems.org")
# ./spec/bundler/gem_helper_spec.rb:54:in `mock_confirm_message'
# ./spec/bundler/gem_helper_spec.rb:286:in `block (6 levels) in <top (required)>'
# ./spec/spec_helper.rb:100:in `block (2 levels) in <top (required)>'
```
This is due to some RSpec weirdness. In particular,
https://github.com/rspec/rspec-core/issues/2544.
If you have an outer `before(:each)` block, and an inner `around(:each)`
block, it turns out that the inner `around(:each)` runs before the outer
`before(:each)`. This is very unintuitive and might change in future
RSpec's. In our case, it causes a particular failure where the `around`
hook would set a value for an environment variable, and then it would
be unintentionally reset by our global `before` hook.
We workaround the issue by changing the global `before` hook to an
`around` hook, so that the ordering respects nesting.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Reproducible with
```
bin/rspec \
./spec/bundler/ruby_version_spec.rb[1:1:8:5:3:1] \
./spec/install/gemfile/ruby_spec.rb[1:4] \
--seed 48267
```
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Instead of creating a separate rake task. This should allow the tests to
properly clean after themselves also when not run through rake.
|
| | | |
| | |
| | |
| | | |
When `requires_sudo` would not properly reset state.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
constants
This test was relying on a specifc constant to already be defined for the test to
pass. There is another test in `spec/bundler/plugin_spec.rb` that was
resetting these constants and causing this test to fail
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7177: `bundle gem` spec refactor r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that before I figured I needed to revert https://github.com/bundler/bundler/pull/7138 due to the specs no longer being stable, I debugged some failures in the `bundle gem` suite and ended up writing some refactorings.
### What was your diagnosis of the problem?
My diagnosis was that something was wrong with these tests but in the end they were just flaky because of #7038.
In any case, I think the refactorings I wrote improve readabily. In particular, extending the global `reset!` method called before each spec, and reusing it again in the middle of some of these specs was kind of confusing.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
7180: Configure Sponsor button on GitHub r=hsbt a=indirect
Once this file is committed to the repo, GitHub will let us enable a "Sponsor" button, as part of [GitHub's new sponsorship system](https://github.blog/2019-05-23-announcing-github-sponsors-a-new-way-to-contribute-to-open-source/).
Co-authored-by: André Arko <andre@arko.net>
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7163: Remove `global_path_appends_ruby_scope` setting r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was we're artificially holding shipping bug fixes like the fact the ruby scope is not included in the install path when `BUNDLE_PATH` is used as an environment variable or global setting.
### What was your diagnosis of the problem?
My diagnosis was that we can remove the setting, and that it's fine that affected users rerun `bundle install` to get their installation paths fixed.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the setting.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a bug fix, so it makes no sense to make it configurable. Also,
the fix is unlikely to cause problems other than maybe needing a fresh
`bundle install` on some edge cases. So, let's ship the fix and remove
the setting.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7174: Revert "Remove unused filter" r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I removed the `:git` filter from our specs in ac282dc9de5e20db85e9cdf23b97763a2a2cc292 because I thought it was unused, but it's not.
### What was your diagnosis of the problem?
My diagnosis was that the filter is actually used once:
https://github.com/bundler/bundler/blob/3ec8165eec0a1af8c45ee258d3e7cb61fba875a2/spec/update/git_spec.rb#L162
### What is your fix for the problem, implemented in this PR?
My fix is to revert the commit.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit ac282dc9de5e20db85e9cdf23b97763a2a2cc292.
Because the filter is actually used once:
https://github.com/bundler/bundler/blob/3ec8165eec0a1af8c45ee258d3e7cb61fba875a2/spec/update/git_spec.rb#L162
My bad.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7166: Better test specific file searching r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that in #7138 I removed some test specific code from lib, but it's not quite working.
### What was your diagnosis of the problem?
My diagnosis was that the mocking I used to fix the issue of bundler looking for files outside of bundler's clone doesn't work inside subprocesses, which many of our specs use. That means some specs were currently failing if you have Gemfile's on `.bundle` folders up in the directory hierarchy ascending from your bundler's clone
### What is your fix for the problem, implemented in this PR?
My fix is revert to the previous approach of using a test specific environment variable to prevent search up higher than the test directory when running our specs.
### Why did you choose this fix out of the possible options?
I initially tried to monkeypatch the gemfile finding helpers only inside specs, but that caused load order issues (I monkeypatched the helpers insde `support/hax.rb`, that caused the monkeypatched lib code to be loaded _before_ the rest of `bundler`, which caused issues in some specs).
Overall, the old approach is the only one that works without issues, so I'm reverting to it, at least for now.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I tried monkeypatching the gemfile finder methods in hax.rb, but that
resulted in loading parts of bundler too early, and getting redefinition
warnings when loading them again from exe/bundle, resulting in actual
errors in some cases. The fix for that required eagerly loading the
monkeypatched parts of bundler, but that involves changing lib just for
the sake of making existing tests pass, and that's what the original
changes intend to avoid.
So, I'm just reverting to the previous approach of setting an
environment variable just for testing and check that.
Reverts 11597fef24274bf1542384512faed697d7f41e3b.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7062: Remove version overwriting hacks r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we are doing some hacks in our version file that are... dangerous. At very least they cause "circular problems" like #6927, but I also have bad feelings about it.
### What was your diagnosis of the problem?
My diagnosis was we're overwriting the version of the currently loaded bundler :grimacing:. This hack is _almost_ unnecessary (see the spec run here with the hack fully removed: https://travis-ci.org/bundler/bundler/builds/509497021. Only three jobs failed, and for old rubies/rubygems/bundler).
### What is your fix for the problem, implemented in this PR?
My fix is to limit the hack to `bundler`'s spec run, since it's only needed there.
### Why did you choose this fix out of the possible options?
I chose this fix because fully getting the build green with the hack fully removed is a bit of work. I dedicated a bit of time to investigate one of the failures and it all comes down to the priority of loading default gems vs `-I`. So I think something like https://github.com/rubygems/rubygems/pull/1868 should fix it. But that's out of the scope of this PR.
Closes #6927.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
By doing this we avoid circular requires (`rubygems` requires `bundler` via
`USE_GEMDEPS`, `bundler` requires `rubygems` when loading its own version), and
also redefinition warnings when the `bundler.gemspec` is evaluated with
`rubygems` already loaded (for example, when running `ruby setup.rb`
from `rubygems` repo).
But most importantly, we avoid leaking from a bundler installation to a
different one, something quite common since bundler is a default gem.
The previous hack meant acting like that didn't happen, but seems
actually quite dangerous.
We can do this due to the previous work of making all of bundler
internal requires not rely on the LOAD_PATH, and thus making it
impossible to leak to another copy of bundler.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
This way, we will never leak to a different bundler copy.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
Otherwise it could happen that support/hax defines Bundler::VERSION first,
and then the real version file redefines it. Not at the moment due to
the version overwriting hacks in our version.rb file, but those will be
removed.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7156: Improve fileutils require r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was there's [upstream changes in fileutils](https://github.com/ruby/fileutils/pull/35).
### What is your fix for the problem, implemented in this PR?
My fix is to port the upstream changes, which consist of using `require_relative` everywhere.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7167: Minor spec improvements r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that some specs had harcoded paths from @indirect's file system. :sweat_smile:. These lockfiles are clearly incorrect but specs are not failing.
### What was your diagnosis of the problem?
My diagnosis is that these lockfiles are unnecessary for these tests and don't affect what these tests are testing.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the lockfiles.
As a consequence of the change, the "comment numbering" got messed up. So I removed the numbering while keeping the comments to avoid that problem from happening again in the future.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | | |
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | | |
The lock files are not relevant for the tests, and they are incorrect
anyways.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7118: Refactors to `bundle add` r=deivid-rodriguez a=ryanfox1985
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 no problem just code refactors.
### What was your diagnosis of the problem?
My diagnosis was the possibility to reorganize the code to make clean and more readable.
### What is your fix for the problem, implemented in this PR?
My fix reorganize the code, good usage of the attributes.
Co-authored-by: Guillermo Guerrero <wolf.fox1985@gmail.com>
|
| | | | | |
|
