| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
The `rubygems:push` task is defined as a prerequisite to the `release`
task as well. And since it's defined earlier, it seems to be run prior
to the other prerequisites.
That is not what we want here. We want every prerequisite satisfied
_before_ actually pushing the gem.
|
| |
|
|
|
|
| |
The only thing that really makes the gem available through rubygems is
the actual release tag. Everything else should be a prerequisite to that
in my opinion.
|
| | |
|
| |
|
|
|
| |
If you don't have `ronn` installed, the `man:check` task will fail but
it won't let you know the exact reason.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6112: Add a spec for installing git deps after packaging without git r=deivid-rodriguez a=segiddins
### What was the end-user problem that led to this PR?
The problem was v1.15 seemed to break installing without git when the git deps had already been packaged (see https://github.com/bundler/bundler/issues/6066).
### What was your diagnosis of the problem?
My diagnosis was we actually seemed to have fixed this for 1.16.
### What is your fix for the problem, implemented in this PR?
My fix adds a test to ensure we won't regress.
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7332: Fix version number in release playbook r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I'm about to release bundler, but I'm unsure which one is the right version number.
### What was your diagnosis of the problem?
My diagnosis was that the release playbook is probably wrong, because looking at https://rubygems.org/gems/bundler/versions, we don't really ship `.pre.0`. versions.
### What is your fix for the problem, implemented in this PR?
My fix is to document `.pre.1` as the first prerelease on a minor series, since that's what we usually do.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/
|
|
|
| |
The first prerelease of a bundler minor series is usually `.pre.1`, not
`.pre.0`.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7295: Changelog for first 2.1.0 pre-release r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I want to release a first pre-release of bundler 2.1.0, but I don't have a changelog for it.
### What was your diagnosis of the problem?
My diagnosis was that I needed to compile a changelog.
### What is your fix for the problem, implemented in this PR?
My fix is write the changelog.
### Why did you choose this fix out of the possible options?
I chose this fix because we used to have some automated change log handling, but I'm not sure how it work, so I instead just through each PR including user facing changes manually, with the aid of some helper tasks we have in our Rakefile.
This is still a WIP, because I might include some more PRs, and I also want to elaborate a bit on the deprecations that will get enabled, but it should be ready for an initial review.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| |
| |
| | |
This should be ready now.
|
| |/
|
|
|
| |
It also includes an upgrading document with some explanations about the
new deprecations and how they map to breaking changes in bundler 3.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7307: Deprecate `--path` flag to `bundle check` (and related fixes) r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that this flag should also be deprecated for these commands in preparation for bundler no longer remembering CLI flags.
### What was your diagnosis of the problem?
My diagnosis was that, on bundler 3, the standard use case for `bundle check --path` will no longer work, namely:
```
$ bundle check --path .bundle
The following gems are missing
* rake (12.3.3)
Install missing gems with `bundle install`
$ bundle install
Fetching gem metadata from https://rubygems.org/.
Installing rake 12.3.3
Using bundler 2.1.0.pre.1
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Bundled gems are installed into `./.bundle`
```
In the case of `bundle cache --path`, it has never really work as I expect
So we should deprecate `bundle check --path` and instead use whatever path is configured.
The cache of `bundle cache --path` is not as clear. Currently it does remember the flag for subsequent `bundle install` runs, but it does not change the location where subsequent `bundle cache` or `bundle install` runs save their cache. So I'm not sure how the current behavior is useful.
### What is your fix for the problem, implemented in this PR?
My fix is, pending further discussion on what the expected behavior for `bundle cache` is, to only deprecate `bundle check --path`, and in the case of `bundle cache` I only fixed the option description to not say it remembers the option in bundler 3.
Finally, I added a minor change in the deprecation message to recommend `bundle config set path <path>` instead of `bundle config path <path>`, because the latter is deprecated.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the subset of all this that seemed clearly like the way to go.
Fixes #7300.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| |
| |
| | |
And skip them all for bundler 3.
|
| | | |
|
| | |
| |
| |
| | |
To not mention that the flag is remembered when it's not.
|
| | | |
|
| | |
| |
| |
| | |
It was suggested a deprecated command as a fix.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7329: Undo auto multiplatform r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that since #7215, more Gemfiles are going to fail resolution because of the current issues with multiplatform support, and that we'll be pushing current multiplatform problems into all users because bundler will resolve and lock all platforms included on a Gemfile by default.
### What was your diagnosis of the problem?
My diagnosis was that we probably need better multiplatform support before we start resolving all platforms by default.
### What is your fix for the problem, implemented in this PR?
My fix is to revert the relevant commits from #7215. I'll try to revisit in the future.
### Why did you choose this fix out of the possible options?
I chose this fix because it goes back to how things were before.
Closes #7315.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | | |
This reverts commit 3dc509e645abb497e4dc92a7c42be471ff87db0b.
|
| | | |
| | |
| | |
| | | |
This reverts commit 00b095b98fe4bd44950beaf3bc9f1d91eac7b69e.
|
| | | |
| | |
| | |
| | | |
This reverts commit 52c5a0eedec34b5d86464b3cf135dc2002486f1d.
|
| |/ /
| |
| |
| | |
This reverts commit 3a2d2f025081755bdb38af660897e7b2f749a33a.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7324: Remove `:ruby_core` tag for ruby core r=hsbt a=hsbt
This pull request is backported from https://github.com/ruby/ruby/pull/2380
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* These seem to consistenly pass already
* Show actual command when running `make test-bundler`
Current the setup command that installs the necessary gems for testing
bundler was printed, but not the actual command that runs the tests.
That was a bit confusing.
* Borrow trick from setproctitle specs
* A title that long doesn't get set sometimes
No idea why, but the test doesn't need that the title is that long.
* Fix most gem helper spec ruby-core failures
* Fix the rest of the gem helper failures
* Fix version spec by improving the assertion
* Remove unnecessary `BUNDLE_RUBY` environment var
We can use `RUBY` when necessary, and `BUNDLE_RUBY` is not a good name
because bundler considers `BUNDLE_*` variables as settings.
* Rename `BUNDLE_GEM` to `GEM_COMMAND`
This is more descriptive I think, and also friendlier for bundler
because `BUNDLE_` env variables are interpreted by bundler as settings,
and this is not a bundler setting.
This fixes one bundler spec failure in config specs against ruby-core.
* Fix quality spec when run in core
Use the proper path helper.
* Fix dummy lib builder to never load default gems
If a dummy library is named as a default gem, when requiring the library
from its executable, the default gem would be loaded when running from
core, because in core all default gems share path with bundler, and thus
they are always in the $LOAD_PATH. We fix the issue by loading lib
relatively inside dummy lib executables.
* More exact assertions
Sometimes I have the problem that I do some "print debugging" inside
specs, and suddently the spec passes. This happens when the assertion is
too relaxed, and the things I print make it match, specially when they
are simple strings like "1.0" than can be easily be part of gem paths
that I print for debugging.
I fix this by making a more exact assertion.
* Detect the correct shebang when ENV["RUBY"] is set
* Relax assertion
So that the spec passes even if another paths containing "ext" are in
the load path. This works to fix a ruby-core issue, but it's a better
assertion in general. We just want to know that the extension path was
added.
* Use folder structure independent path helper
It should fix this spec for ruby-core.
* Fix the last failing spec on ruby-core
* Skip `bundle open <default_gem>` spec when no default gems
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7322: Fix comments and messages to refer to https url r=bronzdoc a=giraffate
### What was the end-user problem that led to this PR?
End-users experience 301 redirect, or unintentionally visit URL with http.
### What was your diagnosis of the problem?
Following are some examples using curl to explain this problem.
```
$ curl -I http://github.com/capistrano/bundler
HTTP/1.1 301 Moved Permanently
Content-length: 0
Location: https://github.com/capistrano/bundler
```
```
$ curl -I http://guides.rubygems.org/gems-with-extensions/
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Server: GitHub.com
Location: https://guides.rubygems.org/gems-with-extensions/
X-GitHub-Request-Id: 0A1A:1377:32938B:35C160:5D5D5A84
Content-Length: 162
Accept-Ranges: bytes
Date: Wed, 21 Aug 2019 14:51:49 GMT
Via: 1.1 varnish
Age: 0
Connection: keep-alive
X-Served-By: cache-tyo19949-TYO
X-Cache: MISS
X-Cache-Hits: 0
X-Timer: S1566399109.014809,VS0,VE168
Vary: Accept-Encoding
X-Fastly-Request-ID: 9357ee98e56565f92489c8a4e03235ab60eeb27f
```
### What is your fix for the problem, implemented in this PR?
My fix is to replace http URLs with https URLs.
### Why did you choose this fix out of the possible options?
It's because this fix is simple and easy.
Co-authored-by: Takayuki Nakata <f.seasons017@gmail.com>
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7321: Don't (yet) enable parallelization in CI r=bronzdoc a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that unfortunately #7317 broken rubygems test suite. See https://github.com/rubygems/rubygems/pull/2888.
### What was your diagnosis of the problem?
My diagnosis was that it has some issues.
### What is your fix for the problem, implemented in this PR?
My fix is to not (yet) use it in CI, so we can keep using it locally and investigating these issues without interfering with our CI. In a while we reevaluate how it is working a consider enabling in CI.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / /
| | |
| | |
| | | |
Since it still has issues.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7317: Parallelize test suite (Take 2) r=hsbt a=hsbt
### What was the end-user problem that led to this PR?
This branch reduced test time of bundler.
### What was your diagnosis of the problem?
#7232 has a conflict with the current master branch.
### What is your fix for the problem, implemented in this PR?
I picked a commit for parallelized tests from #7232
### Why did you choose this fix out of the possible options?
Fixed https://github.com/bundler/bundler/pull/7232
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7310: Freeze time to avoid failures at midnight r=deivid-rodriguez a=kazu9su
### What was the end-user problem that led to this PR?
The problem was it will potentially fail if tests are executed around midnight
### What was your diagnosis of the problem?
My diagnosis was it should freeze time when executing spec
### What is your fix for the problem, implemented in this PR?
My fix is mocking `Time.now` when executing `Bundler::BuildMetadata` specs
### Why did you choose this fix out of the possible options?
I chose this fix because it doesn't have effects on other specs.
Co-authored-by: lolwut <lol@wut.com>
|
| | |/
| |
| |
| |
| |
| | |
Specify just a string
set @built_at as nil before testing
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7313: Fix a couple of typos r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was typos.
### What is your fix for the problem, implemented in this PR?
My fix is to correct typos.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7312: Remove old rubies stuff no longer needed r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that was still some code specific to old rubies we no longer support.
### What is your fix for the problem, implemented in this PR?
My fix is to remove that code.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | | |
Our current set of specs is the same for all supported rubies, and we
should keep it that way.
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7274: Fix more leaks to default copy of bundler r=hsbt a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that in some places, it was still possible to end up requiring files in a different copy of bundler (the default copy). I noticed this when I removed a rubygems monkeypatch from the test suite that was preventing the default copy of bundler from being activated when requiring files.
This thing:
https://github.com/bundler/bundler/blob/e1c518363641208429f397170354054b3d28effd/spec/support/hax.rb#L15-L20
### What was your diagnosis of the problem?
My diagnosis was that I should use relative requires wherever they were missing.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the rubygems hack, migrate the rest of the internal requires to be relative, and also introduce some hacks on our specs to make sure we never load the incorrect copy of bundler.
I think this PR should fix the issues in https://github.com/rubygems/rubygems/pull/2863.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The version we're vendoring actually relaxed this restriction back to
2.3.0+, so we can always use the vendored version.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Instead, make sure we always load the local copy of bundler during
specs, and never end up using the default copy.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If we use system bundler, when booting the "outermost" bundler process,
bundler will save the path to the system bundler in BUNDLE_BIN_PATH, and
use it again when booting the "innermost" bundler process (`bundle exec
echo foo`).
That means that second process will use the system bundler path again.
However, we have `-rsupport/hax` in RUBYOPT, so that file will load from
the local copy of bundler, and that file will load `bundler/version`
from the project (not from system), because -Ilib is in the LOAD_PATH.
That will end up causing redefinition errors because the same constant
will be loaded from two different locations.
In general, this is expected behavior, normally you will wrap the
process with `Bundler.with_original_env` to reset the environment.
However, the easiest fix here is to not use system bundler, because it's
not really necessary and thus doesn't help the readability of the spec.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
