summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Try itremove_error_on_stderr_settingDavid Rodríguez2019-04-111-0/+1
|
* Unify stderr helpersDavid Rodríguez2019-04-1120-46/+38
|
* Remove `error_on_stderr` settingDavid Rodríguez2019-04-116-28/+8
|
* Merge #6957Bundlerbot2019-04-1155-445/+345
|\ | | | | | | | | | | | | | | 6957: Move on to bundler 3 r=indirect a=colby-swandale This PR contains the merge of `2-0-stable` to `master` Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Move on to bundler 3David Rodríguez2019-04-1152-434/+287
| | | | | | | | | | | | * Drop bundler 1 stuff from tests. * Move all feature flags to bundler 3 (like they are in 2-0-stable) and get them tested.
| * Fix deprecation warningDavid Rodríguez2019-04-111-1/+1
| |
| * Cherry-pick github source removal from Gemfile templateDavid Rodríguez2019-04-111-2/+0
| |
| * Merge changelog from 2-0-stableDavid Rodríguez2019-04-111-0/+45
| |
| * Fix some specs to not rely on remembering flagsDavid Rodríguez2019-04-112-4/+5
| |
| * Change deploy specs to properly configure deploymentDavid Rodríguez2019-04-111-6/+9
|/
* Merge #7057Bundlerbot2019-04-1117-76/+183
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7057: Review multiple sources deprecation r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that I had not yet reviewed the deprecation about multiple global sources being present on a Gemfile, and thus the specs were skipped. ### What was your diagnosis of the problem? My diagnosis was that we need to delay the removal of multiple sources support to bundler 3, so that we can show the deprecations in the 2.x series. I also noticed that part of the deprecation message was inaccurate. In order to upgrade the warning to an error, you would also need to configure the `lockfile_uses_separate_rubygems_sources` setting. Otherwise you will get an error that these two settings depend on each other and can't be enabled separatedly. ### What is your fix for the problem, implemented in this PR? My fix is to delay these feature flags to bundler 3 so that the deprecation specs pass. Also, since before giving this advice I'd like to study why we have two different settings that can't be enabled separately, and why the can't be merged to a single one, I have removed that part of the message for now. ### Why did you choose this fix out of the possible options? I chose this fix because it keeps me moving with reviewing all the deprecations for bundler 3 breaking changes, and makes sure that the deprecations for this change of behavior are tested (and passing). Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Refactor list specs to not change gemfile sourcesmultiple_sources_deprecationDavid Rodríguez2019-04-082-15/+87
| | | | | | | | | | | | | | | | | | | | Previously, all specs would bundle a Gemfile from the "repo1" source by default. Then, some list specs would end up using a "repo2" source. The behavior when changing repo sources is changing with the `disable_multisource` setting, but it is unrelated to the list command. So, I refactored the list command specs to not change sources, and extracted the behavior change about changing sources to a separate spec.
| * Check the full warning textDavid Rodríguez2019-04-081-1/+8
| |
| * Fix multiple source deprecation spec on bundler 2David Rodríguez2019-04-081-2/+2
| |
| * Move multiple global source removal to bundler 3David Rodríguez2019-04-087-22/+56
| | | | | | | | And fix specs.
| * Merge multisource related settingsDavid Rodríguez2019-04-0810-22/+14
| |
| * Allow running source list specs in isolationDavid Rodríguez2019-04-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Currenty one gets errors like ``` Failure/Error: lock_sources.to_set == replacement_sources.to_set NoMethodError: undefined method `to_set' for #<Array:0x0000560a01cd97c0> Did you mean? to_s ```
| * Unify multiple source deprecation specsDavid Rodríguez2019-04-082-14/+17
| | | | | | | | | | | | Move them to the file where all deprecations are tested. And test just the simple case, since the deprecations logic should be the same for all cases.
| * Remove unnecessary Gemfile creationDavid Rodríguez2019-04-081-1/+0
| | | | | | | | Gemfile is not considered in this situation.
| * Remove redundant `bundle! :install`David Rodríguez2019-04-081-2/+0
| | | | | | | | `install_gemfile!` already runs that.
* | Merge #7110Bundlerbot2019-04-0910-57/+8
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7110: Cleanup old rubies stuff r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that there was still some code specific for old rubies in our code base. ### What is your fix for the problem, implemented in this PR? My fix is to remove that code. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Remove ruby 1.8 compatibility codecleanup_old_rubies_stuffDavid Rodríguez2019-04-081-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | The comment about this being for rubygems 1.8 compatibility seems wrong, it was for ruby 1.8 compatibility, as can be seen by these docs: https://ruby-doc.org/core-1.8.7/Module.html#method-i-instance_methods https://ruby-doc.org/core-1.9.3/Module.html#method-i-instance_methods
| * | Remove QuickLoader mentionDavid Rodríguez2019-04-081-5/+0
| | | | | | | | | | | | No longer provided by ruby since 1.8 times.|
| * | Remove misleading commentDavid Rodríguez2019-04-081-1/+1
| | | | | | | | | | | | The specs needs that LOAD_PATH modification as of today to pass.
| * | Cleanup more stuff only needed for old rubiesDavid Rodríguez2019-04-086-18/+5
| | |
| * | Remove unused constantDavid Rodríguez2019-04-081-14/+0
| | | | | | | | | | | | Stopped being used in 8b749ee85b04307135d368f05275d50e6cbf76a0.
| * | Cleanup old stuffDavid Rodríguez2019-04-081-14/+0
| |/
* | Merge #6951Bundlerbot2019-04-081-13/+14
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6951: Fix symlink spec on ruby 2.6 r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that we were skipping this test on ruby 2.6. Skipping tests on old versions is not much of a problem, but doing it on the latest version is opening the door for regressions. So I want to fix it. ### What was your diagnosis of the problem? My diagnosis was that since bundler is now a default gem, that bundler version is being activated by the spec, but since we are on a 2.0.1 locked bundle, the spec runs into a version mismatch error. ### What is your fix for the problem, implemented in this PR? My fix is to enable the `Kernel.require` rubygems monkeypatch for this case (the `bundle` gem itself), that requires default gem files without activating the specific default version, and thus not forcing end users to use that. Since... that's exactly the problem here. ### Why did you choose this fix out of the possible options? I chose this fix because it makes sense to me. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Fix symlink spec on ruby 2.6fix_symlink_spec_on_ruby_2.6David Rodríguez2019-04-041-9/+7
| | | | | | | | | | | | | | | | | | | | In rubies where there's no default bundler gem, the original test requiring that `bundler/setup` doesn't fail to load was correct. But in rubies where there's a default bundler gem the bug would manifest in a different way, by loading the incorrect default copy of bundler. So we instead check that the copy of bundler that we load is the (expected) symlinked one.
| * Read gemspec binarilyDavid Rodríguez2019-04-041-1/+1
| | | | | | | | | | When running `bin/rspec spec/runtime/setup_spec.rb -e symlink`, I get an "invalid byte sequence in US-ASCII" error. This commit fixes that.
| * Fix incorrect specification name in specDavid Rodríguez2019-04-041-2/+3
| |
| * Fix missing tempfile requireDavid Rodríguez2019-04-041-0/+1
| | | | | | | | | | | | When running `bin/rspec spec/runtime/setup_spec.rb -e symlink`, you'll get an "uninitialized constant `Tempfile`" error. This commit fixes that.
| * Fix missing tmpdir requireDavid Rodríguez2019-04-041-0/+2
| | | | | | | | | | | | When running `bin/rspec spec/runtime/setup_spec.rb -e symlink`, you'll get an "undefined method `mktmpdir' for Dir:Class" error. This commit fixes that.
| * Remove unused variableDavid Rodríguez2019-04-041-1/+0
| |
* | Merge #7104Bundlerbot2019-04-081-0/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7104: Add missing method to rake file r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was any Rake task depending on the `:build_metadata` task is currently failing with ``NameError: undefined local variable or method `bundler_spec' for main:Object``. For example, the release or build tasks. ### What was your diagnosis of the problem? My diagnosis was that I probably broke this during the development environment refactoring. ### What is your fix for the problem, implemented in this PR? My fix is to add the missing method to the file that needs it. ### Why did you choose this fix out of the possible options? I chose this fix because it works and it restores working tasks. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Add missing method to rake filefix_undefined_method_errorDavid Rodríguez2019-04-051-0/+4
| | |
* | | Merge #7105Bundlerbot2019-04-081-153/+157
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7105: Simplify deprecation specs r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was deprecation specs have become convoluted. The spawn many unnecessary subprocesses and do unnecessary work, and have complicated and redundant descriptions. ### What is your fix for the problem, implemented in this PR? My fix is to reduce the nesting level of the specs, simplify descriptions, and refactor test setups so that each test only runs the bare minimum that it needs. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | Remove one more nesting levelsimplify_deprecation_specsDavid Rodríguez2019-04-051-38/+38
| | | | | | | | | | | | | | | | For consistency with other specs.
| * | | Simplify some spec descriptionsDavid Rodríguez2019-04-051-3/+3
| | | |
| * | | Fix major deprecation specs nestingDavid Rodríguez2019-04-051-109/+115
| | | | | | | | | | | | | | | | | | | | They not all need to create & install a Gemfile, so let's do only what's needed. Also the spec descriptions are simpler when no so deeply nested.
| * | | Remove unnecessary Gemfile lineDavid Rodríguez2019-04-051-1/+0
| | | |
| * | | Prefer the standard `install_gemfile!`David Rodríguez2019-04-051-2/+1
| | | |
* | | | Merge #7038Bundlerbot2019-04-061-1/+1
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7038: Strip unknown regexp option line from error format r=hsbt a=k0kubun ### What was the end-user problem that led to this PR? On Gemfile syntax error like `gem 'foo', :path => /unquoted/string/syntax/error`, Ruby 2.7 will show strange error message like: ``` [!] There was an error parsing `Gemfile`: unknown regexp options - trg - ...foo', :path => /unquoted/string/syntax/error ... ^~~~~~~. Bundler cannot continue. ``` due to recent change in Ruby trunk https://github.com/ruby/ruby/commit/b6468b01f7288789ef2e9bf548d81cdadb8ef053. This caused Bundler's [CI failure on ruby/ruby repository](https://dev.azure.com/rubylang/ruby/_build/results?buildId=180&view=logs&jobId=b6208202-37e9-506d-3aed-7f8fc7b76c87&taskId=a8620f99-3e9e-5782-41a8-f55e2d53059e&lineStart=94&lineEnd=95&colStart=1&colEnd=1). Bundler's Travis ruby-head has not failed yet because Travis ruby-head is still a little old. It will fail later and this is fixing the future failure. ### What was your diagnosis of the problem? SyntaxError's message was changed to have an additional message indicating a position of an unknown regexp option like: ``` foo /bar/baz ^~~ ``` or ``` ...oooooooooooooooooooooo /bar/baz ... ^~~ ``` ### What is your fix for the problem, implemented in this PR? My fix tries to strip the new message part because the error line is already shown in another part of `DSLError#to_s`. ### Why did you choose this fix out of the possible options? To keep the best compatibility with older Bundler versions. Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
| * | | | Strip unknown regexp option line from error formatTakashi Kokubun2019-03-141-1/+1
| | | | |
* | | | | Merge #7106Bundlerbot2019-04-052-0/+6
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7106: Cache rubocop in travis-ci r=deivid-rodriguez a=colby-swandale ### What was the end-user problem that led to this PR? We run rubocop on every build that goes through every file looking for any breaking rules. Currently this takes about ~30s to execute. We also have the linting step required to pass before any other steps are executed, so having this step execute as fast as possible is important to developers. I think there is a small optimize we can make to the build time by caching rubocop between builds. ### What is your fix for the problem, implemented in this PR? Have travis cache the results from rubocop between builds to speed up build times Co-authored-by: Colby Swandale <me@colby.fyi>
| * | | | set rubocop to cache into `tmp/rubocop` and have travis cache the foldercolby-rubocop-ci-cacheColby Swandale2019-04-052-0/+6
| | | | |
* | | | | Merge #7093Bundlerbot2019-04-053-1403/+172
|\ \ \ \ \ | |_|_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7093: Merge lockfile spec files r=colby-swandale a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was current lockfile specs are hard to maintain. ### What was your diagnosis of the problem? My diagnosis was that we were maintaining separate files per version for the lockfile specs. I imagine we did this because at some point the lockfiles were too different to make it worth maintaining a single file with some filters on the bundler version. I don't think this is the case anymore. ### What is your fix for the problem, implemented in this PR? My fix is to merge both files. ### Why did you choose this fix out of the possible options? I chose this fix because I think it simplifies maintenance and it gives a quick view of the differences in the lock file format across versions in a single place. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Merge lockfile spec filesmerge_lockfile_specsDavid Rodríguez2019-04-033-1403/+172
| | |_|/ | |/| |
* | | | Merge #7072Bundlerbot2019-04-057-52/+95
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7072: Review `bundle show` deprecation r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was there was some work to do regarding the deprecation of `bundle show` and the `bundle list` introduction. ### What was your diagnosis of the problem? * The command should error out in bundler 3 and was still there. * The command would print erroneous deprecation messages for the `--verbose` and `--outdated` flags. These flags to `bundle show` are undocumented and will be removed in bundler 3. * The `bundle list` help would show the help for the new `list` command that lists groups of (or all) gems in the Gemfile, but its implementation would just be an alias to `bundle show`. ### What is your fix for the problem, implemented in this PR? My fix is to remove the command in bundler 3, to show a different deprecation message when `--outdated` or `--verbose` are used to inform about their removal without replacement, and the inconditionally introduce the new list command without any feature flag. ### Why did you choose this fix out of the possible options? I chose this fix because: * The `--outdated` and `--verbse` options are undocumented, so nobody should be using them. Still, I give a correct deprecation message for any users they might have used them. * The `list` command was super confusing because it was an alias to `show` but that was not documented anywhere. So, I consider find to introduce the new `bundle list` now to match the documentation. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | | | Typo. s/expect/except/David Rodríguez2019-04-051-1/+1
| | | | |
View Lorry Controller Status