summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Add missing changelog datemore_release_fixesDavid Rodríguez2019-09-151-1/+1
|
* Fallback to `release:github` task when no version specifiedDavid Rodríguez2019-09-151-1/+1
|
* Merge #7355Bundlerbot2019-09-152-14/+41
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Document the modified `release:prepare_patch` taskfix_release_task_againDavid Rodríguez2019-09-121-11/+18
| |
| * Restore version bumping to `release:prepare_patch`David Rodríguez2019-09-121-3/+23
|/
* Merge #7350Bundlerbot2019-09-121-38/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Add some loggingfix_release_patch_taskDavid Rodríguez2019-09-101-0/+2
| |
| * This task is no longer "destructive"David Rodríguez2019-09-101-2/+0
| | | | | | | | | | It no longer releases, not touches protected remote branches, so no really need for confirmation.
| * Cherry-pick commits into a new branchDavid Rodríguez2019-09-101-1/+1
| | | | | | | | So we can create a release PR to the stable branch.
| * Simplify `release:patch` taskDavid Rodríguez2019-09-101-37/+4
| |
* | Merge #7353Bundlerbot2019-09-113-3/+3
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * require `rubygems`, not `ubygems`Mike MacDonald2019-09-113-3/+3
|/ | | | The latter does not work on Ruby 2.6.3.
* Merge #7343Bundlerbot2019-09-091-0/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Add 2.1.0.pre.2 changelog entries2.1.0.pre.2_changelogDavid Rodríguez2019-09-051-0/+7
| |
* | Merge #7342Bundlerbot2019-09-092-20/+10
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | Start using automatiek 0.3.0automatiek_0.3David Rodríguez2019-09-042-20/+10
| | |
* | | Merge #7344Bundlerbot2019-09-054-3/+3
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | Ignore the all of warnings with inline_spec.rb of bundler examples.backport-ruby-coreHiroshi SHIBATA2019-09-051-1/+1
| | |
| * | Add guard as same as `==`Kazuhiro NISHIYAMA2019-09-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Try to fix failure at https://github.com/ruby/ruby/runs/207580232#step:10:382 ``` undefined method `name' for "Gemfile.lock":String /home/runner/work/ruby/ruby/lib/bundler/resolver/spec_group.rb:65:in `eql?' ```
| * | Remove github_action_linux tag from bundler examples.Hiroshi SHIBATA2019-09-052-2/+1
|/ / | | | | | | Maybe it has fixed at 5a384e2c08704dc7af9d8d3bdfc475eb8c0723aa
* | Merge #7340Bundlerbot2019-09-043-29/+93
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7340: Fix bundle clean issue r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that `bundle clean` is crashing under some conditions. ### What was your diagnosis of the problem? My diagnosis was that sometimes (when the bundle includes git sourced gems with extensions), it assumes that some paths exist, but they don't. ### What is your fix for the problem, implemented in this PR? My fix is to ignore those paths. ### Why did you choose this fix out of the possible options? I chose this fix because it fixes the issue. Fixes #7338. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Add missing release date in changelogfix_bundle_clean_issueDavid Rodríguez2019-09-011-1/+1
| | |
| * | Fix `bundle clean` regressionDavid Rodríguez2019-09-012-1/+27
| | | | | | | | | | | | | | | It would crash when git gems with extensions were included in the bundle, but excluded through `BUNDLE_WITHOUT`.
| * | Use non deprecated functionality for `bundle clean` specsDavid Rodríguez2019-09-011-27/+65
| | |
* | | Merge #7333Bundlerbot2019-09-032-5/+3
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7333: Release task improvements r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was several issues I had when releasing bundler: * The prerequisites can fail, but the gem is still pushed to rubygems. * Some error messages could be better. * The github release is a postrequisite not a prerequisite for the release task. ### What was your diagnosis of the problem? My diagnosis was that we need to make every prerequisite a prerequisite to the `rubygems:push` task to be really sure the gem is not pushed until every thing else is satisfied. ### What is your fix for the problem, implemented in this PR? My fix implements that idea, plus other few improvements to the release task. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Make sure release prerequisites are really prerequisitesrelease_improvementsDavid Rodríguez2019-08-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | Make releasing to github a prerequisiteDavid Rodríguez2019-08-281-5/+1
| | | | | | | | | | | | | | | | | | 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.
| * | Document the task to push to github releasesDavid Rodríguez2019-08-281-0/+1
| | |
| * | Give a better error on a release failure caseDavid Rodríguez2019-08-281-0/+1
| | | | | | | | | | | | | | | If you don't have `ronn` installed, the `man:check` task will fail but it won't let you know the exact reason.
* | | Merge #7334Bundlerbot2019-09-01705-347/+347
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7334: Test against latest rubies r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that patch level rubies were release, so we should test them. ### What is your fix for the problem, implemented in this PR? My fix is to start using them in CI. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Test against latest rubiesDavid Rodríguez2019-09-01705-347/+347
|/ / /
* | | Merge #7337Bundlerbot2019-09-012-4/+10
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7337: Fix a couple of bundler issues with keyword argument separation r=hsbt a=jeremyevans ### What was the end-user problem that led to this PR? `make test-bundler` in Ruby repository failed with recent changes to separate keyword arguments from positional arguments (see https://bugs.ruby-lang.org/issues/14183). ### What was your diagnosis of the problem? Bundler's specs check for lack of warnings, and the new changes cause warnings that cause Bundler's specs to fail. ### What is your fix for the problem, implemented in this PR? In one case, I fix the code to work with keyword arguments and positional arguments in positional arguments. In the other case, I fix the spec to ignore the keyword argument separation warnings. I fixed this upstream in Ruby already (https://github.com/ruby/ruby/commit/b5b3afadfab4072f55320075ccac6afe333a140c). So this is a request to make bundler use the same patch. You can certainly fix it differently, and there are more related issues to fix I think (they just don't cause test failures yet). The issues definitely need to be fixed if you want bundler's specs to run correctly in Ruby 2.7. ### Why did you choose this fix out of the possible options? Because it was the least amount of effort. Co-authored-by: Jeremy Evans <code@jeremyevans.net>
| * | Fix a couple of bundler issues with keyword argument separationJeremy Evans2019-08-302-4/+10
| |/ | | | | | | | | There are more issues than this, but hopefully this is enough to get make test-bundler passing in CI.
* | Merge #7339Bundlerbot2019-09-0150-50/+50
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7339: Bump man documentation's month r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that CI is green because `rake man:check` is failing. ### What was your diagnosis of the problem? My diagnosis was is that this is a gotcha of our current documentation building workflow. ### What is your fix for the problem, implemented in this PR? I want to address this in the future but for now the easiest for me is to bump the documentation's date once a month. ### Why did you choose this fix out of the possible options? I chose this fix because it's the simplest way to get CI green for me now. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Bump man documentation's monthDavid Rodríguez2019-09-0150-50/+50
|/
* Merge #6112v2.1.0.pre.1Bundlerbot2019-08-271-0/+17
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Add a spec for installing git deps after packaging w/o gitSamuel Giddins2019-08-271-0/+17
| |
* | Merge #7332Bundlerbot2019-08-271-1/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Fix version number in release playbookskip_pre_0_versionsDavid Rodríguez2019-08-271-1/+1
|/ | | | | The first prerelease of a bundler minor series is usually `.pre.1`, not `.pre.0`.
* Merge #7295Bundlerbot2019-08-272-3/+330
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * One round of self-feedbackDavid Rodríguez2019-08-272-34/+30
| | | | | | | | This should be ready now.
| * Changelog for 2.1.0.pre.1changelog_for_next_releaseDavid Rodríguez2019-08-272-3/+334
|/ | | | | It also includes an upgrading document with some explanations about the new deprecations and how they map to breaking changes in bundler 3.
* Merge #7307Bundlerbot2019-08-273-29/+58
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Merge all `bundle check --path` specsdeprecate_path_arg_to_check_and_packageDavid Rodríguez2019-08-161-25/+30
| | | | | | | | And skip them all for bundler 3.
| * Remove duplicated spec filterDavid Rodríguez2019-08-161-1/+1
| |
| * Fix --path option descriptionsDavid Rodríguez2019-08-161-2/+2
| | | | | | | | To not mention that the flag is remembered when it's not.
| * Deprecate `--path` flag to `bundle check`David Rodríguez2019-08-162-0/+24
| |
| * Fix remembered flag deprecation messageDavid Rodríguez2019-08-162-2/+2
| | | | | | | | It was suggested a deprecated command as a fix.
* | Merge #7329Bundlerbot2019-08-279-30/+47
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | Revert "Add all platforms to lockfile by default"undo_auto_multiplatformDavid Rodríguez2019-08-264-32/+6
| | | | | | | | | | | | This reverts commit 3dc509e645abb497e4dc92a7c42be471ff87db0b.
View Lorry Controller Status