summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Delegate should be supported nowdelegate_is_now_supportedDavid Rodríguez2019-12-141-1/+1
| | | | Since `did_you_mean` dropped its dependency on it.
* Merge #7480Bundlerbot2019-12-143-9/+44
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 7480: Vendor thor 1.0.0 r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that `thor` 1.0.0 has been released, so we should vendor it. ### What is your fix for the problem, implemented in this PR? My fix is to vendor it. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Vendor thor 1.0.0David Rodríguez2019-12-143-9/+44
| |
* | Merge #7478Bundlerbot2019-12-132-2/+2
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7478: Revert "Write & read dummy gems binarily" r=deivid-rodriguez a=deivid-rodriguez This reverts commit f11c4757a17bea029e1a83ad67c425ccf16133ff. ### What was the end-user problem that led to this PR? The problem was that since #7451, azure logs are flooded with messages like ``` The file will have its original line endings in your working directory warning: LF will be replaced by CRLF in foo.gemspec. ``` This makes it hard to scan for other potential errors. ### What was your diagnosis of the problem? My diagnosis was that some commit in that PR introduced this warnings. ### What is your fix for the problem, implemented in this PR? My fix is to revert the offending commit. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Revert "Write & read dummy gems binarily"cleanup_windows_ci_logsDavid Rodríguez2019-12-132-2/+2
|/ | | | This reverts commit f11c4757a17bea029e1a83ad67c425ccf16133ff.
* Merge #7477Bundlerbot2019-12-131-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7477: Skip `did_you_mean` and `delegate` failures on MRI 2.7 r=deivid-rodriguez a=deivid-rodriguez # What was the end-user problem that led to this PR? `ruby-head` build [is broken again](https://travis-ci.org/bundler/bundler/jobs/624581155). ### What was your diagnosis of the problem? Ruby 2.7 will turn `did_you_mean` into a default gem. That means that bundler tests that make sure that an arbritary version of default gems can be specified in the `Gemfile` will now run against `did_you_mean`. And this doesn't work because `did_you_mean` is activated in ruby's `prelude.rb`, way before `bundler/setup` is required, so the latest version will always be activated, regardless of what the user specifies. If these versions are not the same, a gem activation conflict error will happen. Note that this problem is not specific to ruby 2.7, it simply gets triggered by the change of making it a default gem, but it would also happen on older versions if the user `did_you_mean` version specified in the `Gemfile` does not match the latest version installed on her system. As a consequence of this, we also get activation trouble because `did_you_mean` depends on `delegate` which is also a default gem on ruby 2.7. This problem _is_ specific to ruby 2.7 because `delegate` was not gemified before that, but can probably be workarounded by removing the `delegate` dependendcy from `did_you_mean`. ### What is your fix for the problem, implemented in this PR? My "fix" allow these failures, because there's not much we can do about this at the moment. However, I'd like to ping @yuki24 and ask how difficult would be to remove the dependency on `delegate` from `did_you_mean`, because that would fix the issue with the `delegate` gem. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Skip `did_you_mean` and `delegate` failures on MRI 2.7skip_did_you_mean_on_2_7David Rodríguez2019-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ruby 2.7 will turn `did_you_mean` into a default gem. That means that bundler tests that make sure that an arbritary version of default gems can be specified in the `Gemfile` will now run against `did_you_mean`. And this doesn't work because `did_you_mean` is activated in ruby's `prelude.rb`, way before `bundler/setup` is required, so the latest version will always be activated, regardless of what the user specifies. If these versions are not the same, a gem activation conflict error will happen. Note that this problem is not specific to ruby 2.7, it simply gets triggered by the change of making it a default gem, but it would also happen on older versions if the user `did_you_mean` version specified in the `Gemfile` does not match the latest version installed on her system. As a consequence of this, we also get activation trouble because `did_you_mean` depends on `delegate` which is also a default gem on ruby 2.7. This problem _is_ specific to ruby 2.7 because `delegate` was not gemified before that, but can probably be workarounded by removing the `delegate` dependendcy from `did_you_mean`.
* | Merge #7475Bundlerbot2019-12-134-12/+12
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7475: Delay deprecation of `bundle config` and `bundle update` without args r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem I was thinking about the upcoming release of bundler 2.1.0, and I'm not convinced about these two deprecations. I'm not necessarily against them, but these command are very common IMO, and we'll be making them harder to run. Again, maybe for good reasons, but still. That will be combined with the fact that: * In this same release, we'll be enabling all of the other deprecations. * Ruby 2.7 will include bundler 2.1 and ruby 2.7 will also come with a lot of warnings about keyword arguments. ### What was your diagnosis of the problem? My diagnosis was that I think it's better to postpone these two deprecations for now. Get the other deprecations going and get user feedback about them, and then worry about these two later. ### What is your fix for the problem, implemented in this PR? My fix is to delay both deprecations. ### Why did you choose this fix out of the possible options? I chose this fix because I don't want to be too annoying to users at this moment. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Delay deprecation of `bundle config` and `bundle update` without argsundeprecate_argless_config_and_updateDavid Rodríguez2019-12-134-12/+12
|/
* Merge #7460Bundlerbot2019-12-1346-115/+4267
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7460: Vendor `uri` library r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that after the gemification of the `uri` library (which will happen in ruby 2.7), `bundler` will activate the default version of the new library inside its own `bundler/setup` code. That means users won't be able to specify the version of the library they want/need to use in their own Gemfiles. ### What was your diagnosis of the problem? My diagnosis was that we should avoid using `uri` inside `bundler/setup` code. ### What is your fix for the problem, implemented in this PR? My fix is to vendor the `uri` library, like we did with `fileutils`. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * No longer need workarounds since our uri version is fixedvendorize_uri_libraryDavid Rodríguez2019-12-081-2/+0
| |
| * Use vendorized version of uri libraryDavid Rodríguez2019-12-0827-81/+81
| |
| * Vendorize "uri" libraryDavid Rodríguez2019-12-0816-26/+4179
| | | | | | | | | | We vendorize it as a dependency of `net-http-persistent`, so usages inside `net-http-persistent` get automatically replaced by `automatiek`.
| * This `require` seems unneededDavid Rodríguez2019-12-081-1/+0
| |
| * Refactor stuff to not load URI if not neededDavid Rodríguez2019-12-082-5/+11
| |
| * Remove unneeded `to_s` callsDavid Rodríguez2019-12-082-2/+2
| |
| * Lazily load uriDavid Rodríguez2019-12-087-9/+5
| |
* | Merge #7476Bundlerbot2019-12-122-13/+13
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7476: Bump RuboCop to 0.77.0 r=deivid-rodriguez a=koic ### What was the end-user problem that led to this PR? RuboCop 0.77.0 has been released. https://github.com/rubocop-hq/rubocop/releases/tag/v0.77.0 This PR updates the following changes. ```console % bin/rake rubocop bin/rubocop --parallel Error: The `Layout/AlignArray` cop has been renamed to `Layout/ArrayAlignment`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/AlignParameters` cop has been renamed to `Layout/ParameterAlignment`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/IndentAssignment` cop has been renamed to `Layout/AssignmentIndentation`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/IndentFirstArgument` cop has been renamed to `Layout/FirstArgumentIndentation`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/IndentFirstArrayElement` cop has been renamed to `Layout/FirstArrayElementIndentation`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/IndentFirstHashElement` cop has been renamed to `Layout/FirstHashElementIndentation`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/LeadingBlankLines` cop has been renamed to `Layout/LeadingEmptyLines`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/TrailingBlankLines` cop has been renamed to `Layout/TrailingEmptyLines`. (obsolete configuration found in .rubocop.yml, please update it) The `Lint/DuplicatedKey` cop has been renamed to `Lint/DuplicateHashKey`. (obsolete configuration found in .rubocop.yml, please update it) The `Lint/MultipleCompare` cop has been renamed to `Lint/MultipleComparison`. (obsolete configuration found in .rubocop.yml, please update it) The `Lint/StringConversionInInterpolation` cop has been renamed to `Lint/RedundantStringCoercion`. (obsolete configuration found in .rubocop.yml, please update it) The `Naming/UncommunicativeBlockParamName` cop has been renamed to `Naming/BlockParameterName`. (obsolete configuration found in .rubocop.yml, please update it) rake aborted! Command failed with status (2): [bin/rubocop --parallel...] /Users/koic/src/github.com/bundler/bundler/Rakefile:123:in `block in <top (required)>' /Users/koic/src/github.com/bundler/bundler/Rakefile:15:in `block in invoke' /Users/koic/src/github.com/bundler/bundler/Rakefile:14:in `invoke' /Users/koic/src/github.com/bundler/bundler/spec/support/rubygems_ext.rb:87:in `load' /Users/koic/src/github.com/bundler/bundler/spec/support/rubygems_ext.rb:87:in `gem_load_and_activate' /Users/koic/src/github.com/bundler/bundler/spec/support/rubygems_ext.rb:45:in `gem_load' Tasks: TOP => rubocop (See full trace by running task with --trace) ``` ### What is your fix for the problem, implemented in this PR? And this PR has auto-correction of .rubocop.yml using Mry gem. https://github.com/pocke/mry ```console % gem i mry Fetching mry-0.77.0.2.gem Successfully installed mry-0.77.0.2 1 gem installed % mry .rubocop.yml ``` Co-authored-by: Koichi ITO <koic.ito@gmail.com>
| * | Bump RuboCop to 0.77.0Koichi ITO2019-12-122-13/+13
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RuboCop 0.77.0 has been released. https://github.com/rubocop-hq/rubocop/releases/tag/v0.77.0 This PR updates the following changes. ```console % bin/rake rubocop bin/rubocop --parallel Error: The `Layout/AlignArray` cop has been renamed to `Layout/ArrayAlignment`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/AlignParameters` cop has been renamed to `Layout/ParameterAlignment`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/IndentAssignment` cop has been renamed to `Layout/AssignmentIndentation`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/IndentFirstArgument` cop has been renamed to `Layout/FirstArgumentIndentation`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/IndentFirstArrayElement` cop has been renamed to `Layout/FirstArrayElementIndentation`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/IndentFirstHashElement` cop has been renamed to `Layout/FirstHashElementIndentation`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/LeadingBlankLines` cop has been renamed to `Layout/LeadingEmptyLines`. (obsolete configuration found in .rubocop.yml, please update it) The `Layout/TrailingBlankLines` cop has been renamed to `Layout/TrailingEmptyLines`. (obsolete configuration found in .rubocop.yml, please update it) The `Lint/DuplicatedKey` cop has been renamed to `Lint/DuplicateHashKey`. (obsolete configuration found in .rubocop.yml, please update it) The `Lint/MultipleCompare` cop has been renamed to `Lint/MultipleComparison`. (obsolete configuration found in .rubocop.yml, please update it) The `Lint/StringConversionInInterpolation` cop has been renamed to `Lint/RedundantStringCoercion`. (obsolete configuration found in .rubocop.yml, please update it) The `Naming/UncommunicativeBlockParamName` cop has been renamed to `Naming/BlockParameterName`. (obsolete configuration found in .rubocop.yml, please update it) rake aborted! Command failed with status (2): [bin/rubocop --parallel...] /Users/koic/src/github.com/bundler/bundler/Rakefile:123:in `block in <top (required)>' /Users/koic/src/github.com/bundler/bundler/Rakefile:15:in `block in invoke' /Users/koic/src/github.com/bundler/bundler/Rakefile:14:in `invoke' /Users/koic/src/github.com/bundler/bundler/spec/support/rubygems_ext.rb:87:in `load' /Users/koic/src/github.com/bundler/bundler/spec/support/rubygems_ext.rb:87:in `gem_load_and_activate' /Users/koic/src/github.com/bundler/bundler/spec/support/rubygems_ext.rb:45:in `gem_load' Tasks: TOP => rubocop (See full trace by running task with --trace) ``` And this PR has auto-correction of .rubocop.yml using Mry gem. https://github.com/pocke/mry ```console % gem i mry Fetching mry-0.77.0.2.gem Successfully installed mry-0.77.0.2 1 gem installed % mry .rubocop.yml ```
* | Merge #7474Bundlerbot2019-12-127-21/+45
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7474: Fix `bundle exec rake install` failing r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I noticed `bundle exec rake install` was failing on my gem using the latest prerelease of bundler. ### What was your diagnosis of the problem? My diagnosis was that `bundler` silences output of rubygems by default, and in a `bundle exec` context, `bundler/setup` is always required by subprocesses. So, the `rake install` task is silencing rubygems, but it requires it to not be silent: https://github.com/bundler/bundler/blob/bada03dd6d4d15828fb5b2cf7f744948e88a69a3/lib/bundler/gem_helper.rb#L91-L92 ### What is your fix for the problem, implemented in this PR? My fix is to wrap the execution of the rubygems subprocess with `Bundler.with_original_env` so that the `gem` command runs without `bundler` involved. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Remove unnecessary -I optionfix_gem_tasksDavid Rodríguez2019-12-101-1/+1
| | | | | | | | This is leftover code that should've been removed on a previous PR.
| * Fix `bundle exec rake install` not workingDavid Rodríguez2019-12-102-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These gem task checks for a specific string in the gem subcommand output. However, if we are inside a bundled environment (`bundle exec rake install` instead of `rake install`), the ruby process will require `bundler/setup` first thing, and initialize a silent UI for rubygems. As a result, the output string will be always empty and the condition for success will always fail. So, even if installation succeeded, user will always be notified of a failure like: ``` foo 1.0 built to pkg/foo-1.0.gem. rake aborted! Couldn't install gem, run `gem install /home/deivid/Code/bundler/tmp/1/bundled_app/pkg/foo-1.0.gem' for more detailed output ... ``` So, don't check for a specific string in the output and only rely on the exit status.
| * Extract a `gem_command` methodDavid Rodríguez2019-12-091-5/+7
| | | | | | | | And use it consistently.
| * Name variable consistenlyDavid Rodríguez2019-12-091-4/+4
| | | | | | | | Like it is named in the other analogous methods.
| * Prefer `be_empty` to `eq("")`David Rodríguez2019-12-095-10/+10
|/
* Merge #7473Bundlerbot2019-12-084-58/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7473: Cleanup some unnecessary code r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was #7460 is very big so I want to extract these changes to a separate PR, so that we're more aware of them. ### What was your diagnosis of the problem? My diagnosis was that this code can be removed. In particular, in the `GemRemoteFetcher` class there was the following comment https://github.com/bundler/bundler/blob/25595896eb0f8dfd004d941093bf1d8f4a39aeeb/lib/bundler/gem_remote_fetcher.rb#L9-L10 After having a look, I think the comment would make sense if where it says "gemstash", it actually meant "bundler". That would make sense to me since this is about fetching remote specs, so I would assume it's the client side running it. Assuming this is the correct interpretation, we can remove the code since our minimum supported rubygems version is 2.5.2, and this code was included in rubygems in 2.5.0. ### What is your fix for the problem, implemented in this PR? My fix is to remove the `GemRemoteFetcher` class, plus simplify other related code. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Remove unused methodmisc_cleanupDavid Rodríguez2019-12-061-6/+0
| |
| * Remove unnecessary code copied from rubygemsDavid Rodríguez2019-12-063-45/+1
| | | | | | | | | | | | | | I think the comment is misleading and it referred to rubygems, not gemstash, because this code is about the client side of things. If this is correct, we can drop it because we don't support any rubygems version under 2.5.2, and the fix was introduced in rubygems 2.5.
| * Remove unnecessary parameter to `fetch_specs`David Rodríguez2019-12-062-7/+5
|/
* Merge #7471Bundlerbot2019-12-0610-45/+83
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7471: Vendor latest thor's master r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I need to pull some changes from latest `thor` master to avoid loading the `uri` library for #7460. ### What is your fix for the problem, implemented in this PR? My fix is to run `bin/rake vendor:thor[master]` and commit changes. Not that I used an `automatiek` version including https://github.com/segiddins/automatiek/pull/7 that avoids some false positive when replacing namespaces. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Vendor latest thor's masterbump_thorDavid Rodríguez2019-12-0610-45/+83
|/
* Merge #7462Bundlerbot2019-12-021-1/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7462: Document running tests in parallel inside a dev environment r=deivid-rodriguez a=colby-swandale ### What was the end-user problem that led to this PR? We do not have any documentation for running the test suite in parallel. Developers working on Bundler may be unaware that the test suite can be executed in parallel to help speed up the time needed to run tests. ### What is your fix for the problem, implemented in this PR? Document how to run the parallel Bundler test suit in the Contributing docs. Co-authored-by: Colby Swandale <me@colby.fyi>
| * fix number ordercolby/document-parallel-rspecColby Swandale2019-12-021-1/+1
| |
| * document running tests in parallel inside a dev environmentColby Swandale2019-11-301-0/+4
| |
* | Merge #7463Bundlerbot2019-12-022-8/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7463: Vendor fileutils 1.4.1 r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was no big deal. Just a discrepancy between the fileutils version we're vendoring and the one that will ship with ruby 2.7. This doesn't cause any issues, but I prefer that they match. ### What is your fix for the problem, implemented in this PR? My fix is to `bin/rake vendor:fileutils[v1.4.1]` and commit the result. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Vendor fileutils 1.4.1fileutils_1_4_1David Rodríguez2019-11-302-8/+3
| | |
* | | Merge #7464Bundlerbot2019-12-014-60/+29
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7464: Improve rubygems switcher r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was we have some code in our tests to make sure that the `ENV["RGV"]` variable we use to set the rubygems version we want to test bundler against is always respected, including every subprocess our tests start. However: * The code was overly complicated. * It didn't support custom branches, for example, `RGV=lazily_load_uri`. This is a feature I find very useful when a PR you're working on also need some changes in the rubygems side, like it happened to me at #7460. ### What was your diagnosis of the problem? My diagnosis was that all the code needs to do is: * Set up the location of the rubygems code we'll test bundler against, be it a path, a branch, or a released version. * Modify `RUBYOPT` to include that location in the LOAD_PATH, so that `rubygems` is always loaded from there instead of the system's version. ### What is your fix for the problem, implemented in this PR? My fix is to do just that, remove all the stuff that wasn't needed, and do a bit of renaming to improve readability. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Rename `unrequire_rubygems` to `reexec`improve_rubygems_switcherDavid Rodríguez2019-12-011-2/+2
| | | | | | | | | | | | | | | | I don't think "unrequire" is a good name for what this method does.
| * | | Rename `env_version` to `source`David Rodríguez2019-12-011-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | This is usually provided as an `ENV` variable but that's completely transparent to this class. Also, this is not always a version number. I think something like "source" is a better fit.
| * | | Rename `target_tag_version` to `target_tag`David Rodríguez2019-12-011-5/+5
| | | | | | | | | | | | | | | | Since it's always a tag, not a version number.
| * | | Improve rubygems switching codeDavid Rodríguez2019-12-014-45/+14
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous version was overly complicated and brittle, and didn't support, for example, using custom branches in rubygems inside the `RGV` environment variable. Now the `RGV` env variable supports: * Local paths. * Arbitrary tags or branches in rubygems repo. * Released rubygems versions.
* | | Merge #7465Bundlerbot2019-12-0150-50/+50
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7465: December manpages r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that man pages are out of date. ### What is your fix for the problem, implemented in this PR? My fix is to update them. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | December manpagesdecember_manpagesDavid Rodríguez2019-12-0150-50/+50
|/ /
* | Merge #7418Bundlerbot2019-11-292-31/+53
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 7418: Restore previous BUNDLE_GEMFILE in bundler/inline r=deivid-rodriguez a=fatkodima [Without spacing changes](https://github.com/bundler/bundler/pull/7418/files?w=1) Closes #7159 Co-authored-by: fatkodima <fatkodima123@gmail.com>
| * | Restore previous BUNDLE_GEMFILE in bundler/inlinefatkodima2019-11-222-31/+53
| | |
* | | Merge #7461Bundlerbot2019-11-291-0/+1
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7461: Set parallel_tests to output progress in the same format as regular RSpec r=deivid-rodriguez a=colby-swandale # What was the end-user problem that led to this PR? When running tests using the `parallel_test` tool, there will be no output on the terminal to show the progress or result of the test suit. ``` $ ./bin/parallel_rspec spec 8 processes for 162 specs, ~ 20 specs per process Took 576 seconds (9:36) ``` You have to go diving into a file that's located in `tmp/parallel_runtime_rspec.log`. It would be better to have the output that we get from the regular `./bin/rspec` and show the progress/result of the test suit. ### What was your diagnosis of the problem? Run the parallel test suit using `./bin/parallel_rspec spec` ### What is your fix for the problem, implemented in this PR? Add the additional `progress` formatter to the parallel rspec configuration Co-authored-by: Colby Swandale <me@colby.fyi>
| * | Set parallel_tests to also output rspec progresscolby/parallel-rspec-outputColby Swandale2019-11-301-0/+1
|/ /
* | Merge #7459Bundlerbot2019-11-291-9/+12
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7459: Unskip quality specs r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was after 5003a436765eb50d9208ffdce4bbe46cf0d6d63b backported from ruby-core, quality_specs are no longer run, not even in our repo. ### What was your diagnosis of the problem? My diagnosis was that the condition to check whether the root folder is a git folder was incorrect. ### What is your fix for the problem, implemented in this PR? My fix is to correct the condition. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Fix condition to verify root is a git directoryunskip_quality_specsDavid Rodríguez2019-11-281-1/+1
| | |
| * | Extract git check logic to a methodDavid Rodríguez2019-11-281-9/+12
| | |