summaryrefslogtreecommitdiff
path: root/spec
Commit message (Collapse)AuthorAgeFilesLines
* Unify deployment setting and flagimprove_deployment_flagDavid Rodríguez2019-12-313-3/+16
| | | | | | Previously, we were recommending `bundle config deployment true; bundle install` as an alternative to `bundle install --deployment`, but they were not working equally.
* Add missing specsDavid Rodríguez2019-12-311-0/+10
|
* Reword spec to be easier to understandDavid Rodríguez2019-12-311-1/+1
|
* Split credentials specs out of the surrounding contextDavid Rodríguez2019-12-311-70/+71
| | | | So that I can change the setup only for them in following commits.
* Improve readabilityDavid Rodríguez2019-12-311-6/+2
| | | | The `let` does not add anything.
* Add a bang to some commands not supposed to failDavid Rodríguez2019-12-311-5/+5
|
* Don't try to installDavid Rodríguez2019-12-311-1/+1
| | | | | Only set the `Gemfile`, since `bundle install`'ing from that source always fails.
* Use raise instead of flunkSutou Kouhei2019-12-311-1/+1
|
* Fix rspec stuck problem for large stderr external commandSutou Kouhei2019-12-311-2/+4
|
* Add ruby2_keywordsSutou Kouhei2019-12-313-3/+3
|
* Fix `rake build` when path has spaces on itfix/rake_build_with_spaced_pathDavid Rodríguez2019-12-201-0/+14
|
* Make sure to `require "rubygems"` explicitlyrequire_rubygemsDavid Rodríguez2019-12-181-0/+6
| | | | | | Some setups have `--disable=gems` in `RUBYOPT`, and sometimes use `bundler` without modifying that env. Let's not break those setups just to save a `require`.
* Fix another silent rubygems issuefix_another_silent_rubygems_issueDavid Rodríguez2019-12-161-0/+6
| | | | | | | | | | | | | | We might be shelling out to rubygems in a `bundle exec` context. In the case where we don't shell out to the `gem` binstub directly, the previous trick wouldn't work. Instead, reset the rubygems ui right after `bundler/setup`, so that if we end up shelling out to rubygems, it will use its default shell (non-silent). The best place to fix this would probably be right inside the `gem` script, but even if we fix it there, we'll need workarounds for previous rubygems versions inside `bundler` so I think this is good for now.
* Merge #7482Bundlerbot2019-12-144-4/+8
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7482: Fixed test failures with gem command path on ruby core repo r=deivid-rodriguez a=hsbt ### What was the end-user problem that led to this PR? Some of the examples failed with ruby-core repository. ### What was your diagnosis of the problem? The ruby-core repository used `gem` commands under the its repository named `bin/gem` directory. But the current examples points `gem` command with a global path. ### What is your fix for the problem, implemented in this PR? I fixed them used by `ruby_core?` helper methods. Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
| * Fixed test failures with gem command path on ruby core repo.fixed-bundler-specs-on-ruby-repoHiroshi SHIBATA2019-12-144-4/+8
| |
* | Delegate should be supported nowdelegate_is_now_supportedDavid Rodríguez2019-12-141-1/+1
|/ | | | Since `did_you_mean` dropped its dependency on it.
* 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`.
* | Delay deprecation of `bundle config` and `bundle update` without argsundeprecate_argless_config_and_updateDavid Rodríguez2019-12-131-9/+9
|/
* Merge #7460Bundlerbot2019-12-1316-60/+58
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0815-58/+58
| |
* | Bump RuboCop to 0.77.0Koichi ITO2019-12-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ```
* | 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-101-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Prefer `be_empty` to `eq("")`David Rodríguez2019-12-095-10/+10
|/
* Remove unnecessary parameter to `fetch_specs`David Rodríguez2019-12-061-1/+1
|
* 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 #7418Bundlerbot2019-11-291-0/+17
|\ | | | | | | | | | | | | | | | | | | 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-221-0/+17
| |
* | 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
| | |
* | | Use activation hack in default gem activation specsDavid Rodríguez2019-11-281-2/+2
| | | | | | | | | | | | | | | It's super useful when figuring out which part of bundler is activating a default gem.
* | | Split default gem activation specsDavid Rodríguez2019-11-281-26/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently they're using a single Gemfile with all default gems, and making sure that all default gems can be activated. It a single default gem is activated by bundler, this results in huge errors messages because the spec still tries to activate all default gems present in the Gemfile, and fails for all of them. Instead, we separate on spec for each default gem, which makes error messages smaller, and helps figuring out the root cause of the issue. In this case, the `uri` gem.
* | | Only consider exempted default gemsDavid Rodríguez2019-11-281-5/+1
| | |
* | | Easier figuring out of default gemsDavid Rodríguez2019-11-281-3/+1
| | | | | | | | | | | | We don't need an extra subprocess.
* | | `Gem::Specification` should always be an `Enumerable`David Rodríguez2019-11-281-3/+1
| | |
* | | `Gem::Specification#activate` should always be definedDavid Rodríguez2019-11-281-10/+8
| | |
* | | Fix a warning in activation hack snippetDavid Rodríguez2019-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | In particular, ``` /path/to/bundler/tmp/1/bundled_app/activation_warning_hack.rb:9: warning: `*' interpreted as argument prefix ```
* | | Don't hide part of backtracesDavid Rodríguez2019-11-281-3/+1
| | |
* | | Always pass env as strings to helpersDavid Rodríguez2019-11-2811-24/+22
|/ /
* | Merge #7455Bundlerbot2019-11-261-2/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7455: Lazily load `open3` r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was `open3` will be gemified in ruby 2.7, and since we use it inside `bundler`, we might activate a version causing a conflict with the user's choice. ### What was your diagnosis of the problem? My diagnosis was that only loading it when needed should be better. ### What is your fix for the problem, implemented in this PR? My fix is to lazily load it. I expect this PR to fix [some of the errors](https://travis-ci.org/bundler/bundler/jobs/615940817) currently happening in our CI against ruby-head. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Lazily load `open3`David Rodríguez2019-11-261-2/+1
| | | | | | | | | | | | | | | Since it's a default gem now, it's better to load it as late as possible.
* | | Merge #7419Bundlerbot2019-11-261-0/+20
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 7419: Add :glob to git source uniqueness r=deivid-rodriguez a=fatkodima Closes #7346 Co-authored-by: fatkodima <fatkodima123@gmail.com>
| * | Add :glob to git source uniquenessfatkodima2019-11-211-0/+20
| |/
View Lorry Controller Status