| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
And move its description on top of the correct task, `man:build`, so
that it appears under `bin/rake -T`.
|
|
|
|
|
| |
Instead of creating a separate rake task. This should allow the tests to
properly clean after themselves also when not run through rake.
|
|
|
|
|
|
|
|
| |
The current numbers are misleading and coverage tracking doesn't work in
most of the places since the current test suite is mostly based on
spawning subprocesses, and coverage doesn't get properly tracked there.
Let's revisit this in the future.
|
|
|
|
| |
So that `rake install:local` at least works.
|
|
|
|
|
| |
The ronn gem is needed for building man pages, that's already guarded.
The `release` task is irrelevant.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7070: Improve cross repo integration r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that we had on `rubygems`, we're not testing bundler against the rubygems checkout of each PR, but against master. That is confusing because developers assume that the PRs tests will run against the PRs code, but this is currently not true.
### What was your diagnosis of the problem?
My diagnosis was that on rubygems we are [specifying `RGV=master`](https://github.com/rubygems/rubygems/blob/fa6e547330e97b417ed11f262d68d03c57abeeda/.travis.yml#L12) in our TravisCI matrix. And what `bundler` does with that is to clone rubygems master under `tmp/rubygems` and use that. Thus your rubygems PR is not really tested.
### What is your fix for the problem, implemented in this PR?
My fix is to rework the setup to accept an `RGV` environment variable when it contains. In that case, no git operations will be performed, and that path will be used directly and assumed to contain a rubygems checkout.
I also refactored a few things about the setup while at it.
### Why did you choose this fix out of the possible options?
There were existing tasks to test bundler against a rubygems checkout, but they were unused and they expected a `RG` environment variable instead. I decided to reuse these tasks, but make them pick up the `RGV` as long as it contains a valid path. I chose this fix because it works and it doesn't make the existing setup too different.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Since it's meant for CI.
|
| |
| |
| |
| | |
Delegate everything to `bin/with_rubygems` instead.
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7074: Remove unnecessary test stuff r=colby-swandale a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that our test setup could be simpler.
### What was your diagnosis of the problem?
My diagnosis was that some lines installing test gem dependencies could be removed from the Rakefile, because the tests already detect this situation and auto-install test gems appropriately.
### What is your fix for the problem, implemented in this PR?
My fix is to remove the lines. However, removing the lines led to a single test failure that can be explained becase `FileUtils` ends up being required too late, thus skipping one call to `Gem.clear_paths` done in the tests setup so that stuff memoized by `rubygems` is cleared and tests can assume is not loaded yet. The situation is very intricate but I tried to explain it in the commit message.
### Why did you choose this fix out of the possible options?
I chose this fix because it fixes the test failure, but I also plan to propose to eliminate the `autoload` calls in rubygems that also contributed to this issue.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Tests automatically download and install the test gems they need if not
installed, so this should be unnecessary.
However, removing it create a single spec failure only reproducible on a
fresh clone (where the path where the test gems are installed,
`tmp/gems`, has not yet been populated.
The problem was that the code branch that installs the gems uses the
`FileUtils` constant. Accessing that constant makes [this autoload]
trigger the custom rubygems `require` behavior which will end up setting
and memoizing `gem_home` to the value it has at that point (when calling
`to_spec` on the selected default gem). But at that point,
`Gem.clear_paths` call has already happened, that means `gem_home` won't
be changed during the duration of the test because it's memoized.
This situation makes a specific test that updates `ENV["HOME"]` and
expects he path to the configuration file rubygems uses to be updated fail.
This could be fixed by removing the `FileUtils` autoload, or stop
memoizing `Gem.home`, but the simplest fix seemed to require `fileutils`
early, so that `Gem.home` is not memoized again after calling
`Gem.clear_paths`.
[this autoload]: https://github.com/rubygems/rubygems/blob/511a0f5105ca95b8e389bf477b6c7cf3e90be7d1/lib/rubygems/source.rb#L3
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7035: Unify the certificates for rubygems.org to rubygems store. r=deivid-rodriguez a=hsbt
### What was the end-user problem that led to this PR?
The problem was the users have duplicated certificates in their boxes.
### What was your diagnosis of the problem?
I wonder why bundler has a certificates copy from rubygems. It raised up in the tracker of ruby core.
https://bugs.ruby-lang.org/issues/15384
### What is your fix for the problem, implemented in this PR?
I removed the duplicated certificates from bundler, and fallback to rubygems's one.
### Why did you choose this fix out of the possible options?
Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
|
| |
| |
| |
| |
| | |
* Removed CertificateManager and related rake tasks.
* Removed the certificates from bundler internal.
|
| | |
|
| |
| |
| |
| | |
MRI 2.5.4 now regressed and suffers from the same issue as 2.6.2 :S
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Make it consistent with how we do it for `ronn`, and give better
messages for installing `automatiek` if missing.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Previously having another gem with a `ronn` executable would silently
work and fail later with a cryptic error. Now we activate the proper
version, and give a proper error if it fails.
|
| |
| |
| |
| | |
No .rb files in there.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Since the RSpec task now uses the RSpec binstub, we can rely on all the
dance done in there.
|
| | |
|
| |
| |
| |
| | |
We shell out to the binstub so we no longer need the activation dance.
|
| | |
|
| |
| |
| |
| | |
We shell out to the binstubs, so we don't need any activation dance.
|
| |
| |
| |
| |
| | |
This is already done from the spec helper right before the beginning of
the test suite.
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6958: Remove rdiscount indirect development dependency r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I was confused about the `rdiscount` dependency since I didn't see it used anywhere.
### What was your diagnosis of the problem?
My diagnosis was that it's just an indirect dependency (through ronn).
### What is your fix for the problem, implemented in this PR?
My fix is to remove the dependency.
### Why did you choose this fix out of the possible options?
I chose this fix because it will no longer confuse devs into thinking we're actually using it directly.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| |
| |
| | |
We don't use this dependency directly so this is not needed. We put it
there at some point because we needed to pin to a specific version, but
that's no longer the case.
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Now that Bundler no longer supports Ruby <2.3, the Ruby minimum version
requirement that prevented Rubocop from being specified as a development
dependency in the gemspec no longer applies.
Having Rubocop in the gemspec is useful for tools like RubyGems.org or
Bundix that use it as the source of truth for dependencies.
|
| |
|
| |
|