| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7296: Improve exec'ing to the proper rubygems version r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that the `with_rubygems` script is hard to work with, because it does complicated ARGV manipulation before exec'ing.
### What was your diagnosis of the problem?
My diagnosis was that we don't need it.
### What is your fix for the problem, implemented in this PR?
My fix is to implement the same thing in a simpler way.
### Why did you choose this fix out of the possible options?
I chose this fix because it simplifies things.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| | |
We never use system rubygems anymore. Always the local clone.
|
| | |
|
| |
| |
| |
| | |
This should make binstubs more responsive when using `ENV["RGV"]`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead, use a better rubygems version manager that makes sure that
`ENV["RGV"]` usage is always applied, and its usage is centralized at a
single place.
This simplifies the rake task organization and makes it much simpler to
run locally exactly what's run in CI. For example, since it doesn't rely
on the `RGV` being deleted for subsequent subprocesses, it also running
`bin/rake spec:travis` task locally which previously would lead to
```
rake aborted!
RubyGems version is required on Travis!
```
It also reduces duplication making it so that we only need to change the
`.travis.yml` file when updating tested rubies, and not the `Rakefile`
as well.
|
| | |
|
| |
| |
| |
| |
| | |
So that we don't include a `run` method at the top level, which can
conflict with other `run` methods our specs use.
|
| | |
|
| | |
|
| |
| |
| |
| | |
We don't need to keep adding exceptions.
|
|/
|
|
| |
We're checking the same thing in the previous line
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7358: More release fixes r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
I just released [2.1.0.pre.2](https://rubygems.org/gems/bundler/versions/2.1.0.pre.2). It went smoother than 2.1.0.pre.1, but I still got an issue where I unintentionally pushed a release named "v" to github releases.
### What was your diagnosis of the problem?
My diagnosis was that the release task by default should use the version in the gemspec for the `release:github` tasks.
### What is your fix for the problem, implemented in this PR?
My fix adds that fallback.
### Why did you choose this fix out of the possible options?
I chose this fix because it does what the user expects when the task is not passed any arguments.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7359: Spec simplifications r=indirect a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that while working on #7296 and investigating why CI was failing there, I ended up adding several simplifications that are not necessarily related to that PR. In order to make that PR more digestable, I extracted those simplifications and improvements to this separate PR.
### Why did you choose this fix out of the possible options?
I chose this fix because it makes our dev and test environment better and simpler with some little tweaks.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |
| |
| |
| | |
And move filter configuration there.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
No network here.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
| |
Instead of repeating `self` on every method.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7355: Restore version bumping to `release:prepare_patch` r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I removed too much code in #7350.
### What was your diagnosis of the problem?
My diagnosis was that since I removed the auto-bumping `version.rb`, the task no longer works before it tries to cherry-pick changes for the _current_, not the _to be released_ version, so I fails because it finds no open PR for that milestone (because it's already been released).
### What is your fix for the problem, implemented in this PR?
My fix is to restore the code that automatically bumps the version to the next patch level version, and commits that to the release branch.
### Why did you choose this fix out of the possible options?
I chose this fix because it works for me.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7350: Simplify `release:patch` task r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I'm using a slightly different workflow for releasing, but the current rake task does not work my way.
### What was your diagnosis of the problem?
My diagnosis was that previously the release task would push the changelog directly to the release branch and master. The way I'm doing it, I open a regular PR which can be reviewed and merged through bundlerbot just like any other PR.
### What is your fix for the problem, implemented in this PR?
My fix is to adapt the task to the workflow I'm using, and change it to only cherry-pick all the milestoned changes to the stable branch. I renamed it to `release:prepare_patch`.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows the release process itself to be reviewed, and it would allow us to protect the master and stable branches if we wanted to.
It also allows to make sure that CI is passing on the stable branch with all changes cherry-picked, before actually releasing. This could avoid, for example, bugs from being introduced from conflict-resolution errors while cherry-picking changes.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
|
| |
| |
| |
| |
| | |
It no longer releases, not touches protected remote branches, so no
really need for confirmation.
|
| |
| |
| |
| | |
So we can create a release PR to the stable branch.
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7353: require `rubygems`, not `ubygems` in example r=hsbt a=crazymykl
The latter does not work on Ruby 2.6.3.
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 a broken example in the docs.
### What was your diagnosis of the problem?
Ibid.
### What is your fix for the problem, implemented in this PR?
My fix was to write what was likely intended.
### Why did you choose this fix out of the possible options?
I chose this fix because the solution space is pretty small.
Co-authored-by: Mike MacDonald <crazymykl@gmail.com>
|
|/
|
|
| |
The latter does not work on Ruby 2.6.3.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7343: Add 2.1.0.pre.2 changelog entries r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that the changelog needs to be filled before releasing the next pre.
### What is your fix for the problem, implemented in this PR?
My fix is to fill in the user facing changes that I plan to include.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7342: Start using automatiek 0.3.0 r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that I added a feature to automatiek to vendor subdependencies, but we were not using it because it had not yet been released.
### What is your fix for the problem, implemented in this PR?
My fix is to start using the feature now that it has been released.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows us to manage the `net-http-persistent` dependency in an easier way.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7344: Backport the latest ruby core changes r=hsbt a=hsbt
### What was the end-user problem that led to this PR?
The master branch of Bundler with Ruby 2.7 fails some of tests.
### What was your diagnosis of the problem?
It caused by deprecation warnings of Ruby 2.7 and some environmental issues.
### What is your fix for the problem, implemented in this PR?
I fixed them.
* rspec examples of Bundler failed randomly on GitHub Actions of ruby/ruby. We fixed it on `spec_group.rb`
* `github_action_linux` label is no longer required. The current test suite is all green status with GitHub Actions.
* The keyword separation feature warns stub code under the `inline_spec.rb`. I ignore them.
### Why did you choose this fix out of the possible options?
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
Co-authored-by: Kazuhiro NISHIYAMA <zn@mbf.nifty.com>
|
| | | |
|