summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Use rubygems 3.0.2 for testing compatibility modesmaller_ci_matrixDavid Rodríguez2019-02-271-1/+1
|
* Test only the rubygems version each MRI version shipped withDavid Rodríguez2019-02-271-12/+3
|
* Merge #6982Bundlerbot2019-02-2631-186/+64
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6982: Remove unnecessary rubygems filters r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was there's a lot of unnecessary code, specially in specs, that's never run. ### What was your diagnosis of the problem? My diagnosis was that since dropping support for old rubygems versions, this code is no longer necessary. ### What is your fix for the problem, implemented in this PR? My fix is to remove the code. ### Why did you choose this fix out of the possible options? I chose this fix because red is great on diffs. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Remove rubygems compatibility guardremove_unnecessary_rubygems_filtersDavid Rodríguez2019-02-252-13/+0
| | | | | | | | Bundler 2 can't be installed on these rubygems, so it's not necessary.
| * Remove more unnecessary rubygems version checksDavid Rodríguez2019-02-255-56/+27
| |
| * Remove unnecessary old rubygems deprecationDavid Rodríguez2019-02-252-29/+4
| |
| * Remove unnecessary rubygems filters from specsDavid Rodríguez2019-02-2522-88/+33
|/
* Merge #6971Bundlerbot2019-02-243-5/+9
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6971: Fix warning message about bundler version r=colby-swandale a=deivid-rodriguez Fixes #6909. ### What was the end-user problem that led to this PR? The problem was that we're recommending a command to make a warning go away that doesn't really make the warning go away. ### What was your diagnosis of the problem? My diagnosis was that the current recommendation installs the latest bundler, which might not be the same as the version the lock file was created with. If it's not the same, the warning will not go away. ### What is your fix for the problem, implemented in this PR? My fix is to recommend installing exactly the version the lockfile was created with. ### Why did you choose this fix out of the possible options? I chose this fix because it's really simple and it should work. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Fix warning message about bundler versionfix_upgrade_instructionsDavid Rodríguez2019-02-183-5/+9
| | | | | | | | | | | | | | To actually make the warning go away, we need to recommend exactly installing the locked version. Otherwise the latest version gets installed, but not used to being a different major than the one locked, so the warning stays.
* | Merge #6983Bundlerbot2019-02-2417-71/+23
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6983: Remove unnecessary ruby filters r=colby-swandale a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was there's a lot of unnecessary code, specially in specs, that's never run. ### What was your diagnosis of the problem? My diagnosis was that since dropping support for old ruby versions, this code is no longer necessary. ### What is your fix for the problem, implemented in this PR? My fix is to remove the code. ### Why did you choose this fix out of the possible options? I chose this fix because red is great on diffs. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Remove unnecessary ruby filters from specsremove_unnecessary_ruby_filtersDavid Rodríguez2019-02-2215-61/+23
| | |
| * | Remove ruby version major deprecationDavid Rodríguez2019-02-222-10/+0
| | | | | | | | | | | | Since the current master will never run those rubies.
* | | Merge #6984Bundlerbot2019-02-23708-414/+503
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6984: Refresh all VCR cassettes r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was our VCR cassettes contain responses recorded a long time ago, but the real APIs might have changed or give different results since then. ### What was your diagnosis of the problem? My diagnosis was that we should re-record the cassettes every once in a while. ### What is your fix for the problem, implemented in this PR? My fix removes old the previous cassettes and re-records them. ### Why did you choose this fix out of the possible options? I chose this fix because I'm not sure how to do it otherwise. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Refresh all VCR cassettesrefresh_vcr_cassettesDavid Rodríguez2019-02-22708-414/+503
|/ /
* | Merge #6965Bundlerbot2019-02-2210-55/+34
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6965: Turn on deprecations by default r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was we've had deprecations in place for a long time, but we've never displayed them to users by default. ### What was your diagnosis of the problem? My diagnosis was that the current strategy doesn't work because: * Printing deprecations as an optin feature almost never get enabled, so most users don't know about the stuff we'll be deprecating in the future. * Printing deprecations in "deprecation releases" doesn't work well either, because it's unclear how long the deprecation release should last and thus how long we need to hold the final release (that will inhibit installation of the deprecation release). ### What is your fix for the problem, implemented in this PR? My fix is to remove the concept of deprecation releases, and to add a feature flag for printing major deprecations that it's enabled by default. As a extra related change, I also reworded the deprecation messages, because I find the current message "[DEPRECATED FOR 2.0] <Message about the deprecation>" a bit confusing because it's unclear what the version printed is referring to (deprecation horizon? current running version?), so I changed it to just "[DEPRECATED] <Message about the deprecation>". ### Why did you choose this fix out of the possible options? I chose this fix because it (once released) finally makes it so that users will know about our deprecations. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Rename major_deprecations to silence_deprecationsdeprecation_changesDavid Rodríguez2019-02-213-6/+6
| | |
| * | Remove now redundant configsDavid Rodríguez2019-02-212-5/+0
| | | | | | | | | | | | Since deprecations are enabled by default.
| * | Fix deprecations bugDavid Rodríguez2019-02-211-1/+1
| | | | | | | | | | | | | | | Deprecations enabled or not, we only want to print deprecations for the running major version, never for future versions.
| * | Remove major_deprecations feature flagDavid Rodríguez2019-02-213-2/+2
| | | | | | | | | | | | Leave it as a setting with default true value.
| * | Turn on deprecations by defaultDavid Rodríguez2019-02-212-1/+2
| | |
| * | Remove deprecation releasesDavid Rodríguez2019-02-212-18/+1
| | |
| * | Reword deprecation messagesDavid Rodríguez2019-02-216-23/+23
| | | | | | | | | | | | | | | | | | Including the version is confusing, in my opinion, because it's unclear whether it refers to the future version of removal, or to the current running version.
| * | Change some specs checking the wrong streamDavid Rodríguez2019-02-212-6/+6
|/ /
* | Revert "test tty"Colby Swandale2019-02-211-5/+0
| | | | | | | | This reverts commit 32ab05d936efd1fa8373e34790e431e80611587f.
* | test ttyColby Swandale2019-02-211-0/+5
| |
* | Merge #6974Bundlerbot2019-02-2047-162/+181
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6974: Use newer list interface r=indirect a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that our specs emit a lot of deprecations about the list command. ### What was your diagnosis of the problem? My diagnosis was that we are using the deprecated interface to the list command everywhere. ### What is your fix for the problem, implemented in this PR? My fix is to start using the new interface. If we don't use it ourselves, how could we be in a position to tell our users to start using it? ### Why did you choose this fix out of the possible options? I chose this fix because we should do this, at same point, and doing it now simplifies enabling deprecations. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * | Slightly better wording of error messagesuse_newer_list_interfaceDavid Rodríguez2019-02-202-4/+4
| | |
| * | Space after commaDavid Rodríguez2019-02-201-1/+1
| | |
| * | Tweak `bundle config` help to use new interfaceDavid Rodríguez2019-02-201-3/+3
| | |
| * | Fix git source error message recommendationsDavid Rodríguez2019-02-202-4/+25
| | | | | | | | | | | | So the we suggest an actually working command.
| * | More exact match for errors messageDavid Rodríguez2019-02-201-1/+1
| | | | | | | | | | | | Just for consistency with the previous spec.
| * | Remove undefined commandDavid Rodríguez2019-02-191-2/+0
| | |
| * | Use newest interface to `bundle config` everywhereDavid Rodríguez2019-02-1946-152/+152
| | |
* | | Merge #6977Bundlerbot2019-02-202-2/+2
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6977: Update the location of bundler gemspec. r=deivid-rodriguez a=hsbt ### What was the end-user problem that led to this PR? On the ruby core repository has the original patch for the test suite. The current bundler repository was inconsistency status with it. ### What was your diagnosis of the problem? This pull-request was the missing commit of https://github.com/bundler/bundler/pull/6973 ### What is your fix for the problem, implemented in this PR? The test suite of bundler break the inconsistency gemspec location, Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * | | Fixup r66984. Update the location of bundler gemspec.SHIBATA Hiroshi2019-02-202-2/+2
|/ / / | | | | | | | | | git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66993 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* | | Merge #6973Bundlerbot2019-02-207-16/+35
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6973: Backport the latest commits on ruby core repository. r=hsbt a=hsbt ### What was the end-user problem that led to this PR? RSpec example of the bundled bundler was failed on Ruby 2.7 from ruby core repository. I fixed some of the issues on ruby core repository. ### What was your diagnosis of the problem? 1. I fixed the location of `lib/bundler.gemspec` to `lib/bundler/bundler.gemspec` for fixing gemspec issue of Ruby 2.6.1: https://github.com/ruby/ruby/commit/7c9771be02ddc707fea8ec96089c8a100c59f806 2. The current Bundler examples relied on the same versions of Ruby that are the first binary of PATH and rspec invocation binary. But the ruby core repository uses the different versions for them. ### What is your fix for the problem, implemented in this PR? I fixed the location path of bundler.gemspec and uses `ENV['BUNDLE_GEM']` instead of hard-coded `gem` command. ### Why did you choose this fix out of the possible options? There is no options on ruby core repository. I welcome to another options. Co-authored-by: SHIBATA Hiroshi <hsbt@ruby-lang.org>
| * | Fixed cop failuresSHIBATA Hiroshi2019-02-203-3/+3
| | |
| * | Use ENV["BUNDLE_GEM"] instead of gem command provided by system ruby.SHIBATA Hiroshi2019-02-193-8/+15
| | | | | | | | | | | | | | | It break the examples of bundler. Because some examples detect the different version of system ruby than test target version like trunk.
| * | Fixup r66984. It breakes bundler's examples.SHIBATA Hiroshi2019-02-192-2/+2
| | |
| * | The ruby core applied the difference structure from bundler upstreamSHIBATA Hiroshi2019-02-192-7/+19
|/ / | | | | | | repository. We need to modify a configuration for test-bundler.
* | Merge #6969Bundlerbot2019-02-183-16/+8
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6969: Fix redefinition warning r=hsbt a=deivid-rodriguez ### What was the end-user problem that led to this PR? The problem was that the test suite spits some warnings ``` /home/deivid/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/rspec-expectations-3.8.2/lib/rspec/matchers/dsl.rb:72: warning: method redefined; discarding old be_well_formed /home/deivid/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/rspec-expectations-3.8.2/lib/rspec/matchers/dsl.rb:72: warning: previous definition of be_well_formed was here ``` ### What was your diagnosis of the problem? My diagnosis was that we are redefining an RSpec matcher. ### What is your fix for the problem, implemented in this PR? My fix is to define the matcher just once. ### Why did you choose this fix out of the possible options? I chose this fix because moving it to the centralized place where custom matchers are defined made sense to me. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
| * Fix redefinition warningtest_warningDavid Rodríguez2019-02-173-16/+8
|/
* Merge #6968Bundlerbot2019-02-161-1/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6968: Travis "bundle gem" template: Drop unused sudo: false option r=deivid-rodriguez a=olleolleolle ### What was the end-user problem that led to this PR? I reviewed a PR in an Open Source project, and it had this defunct setting from Travis. ### What was your diagnosis of the problem? I was told the `bundle gem` command outputs this directive, and I looked here, and lo, it was. See https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration for historical detail about when it was removed. ### What is your fix for the problem, implemented in this PR? My fix is to **drop** this **unused directive** from the template. ### Why did you choose this fix out of the possible options? I chose this fix because it works the same for the user, with less configuration. Co-authored-by: Olle Jonsson <olle.jonsson@gmail.com>
| * Travis template: Drop unused sudo: false optionOlle Jonsson2019-02-161-1/+0
|/ | | - See https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration for historical detail
* Merge #6899Bundlerbot2019-02-154-1/+87
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6899: Windows CI: Azure Pipelines r=colby-swandale a=janpio ### What was the end-user problem that led to this PR? When I wanted to start to work on #6841 by adding a few tests, I quickly learned that bundler's test suite does not pass on Windows: #6868 ### What was your diagnosis of the problem? I decided to start working on fixing this, and created a few issues already: https://github.com/bundler/bundler/search?q=%22%5BWindows+test+failure%5D%22&unscoped_q=%22%5BWindows+test+failure%5D%22&type=Issues But it become clear to me, that the only way to really track the improvement was to add CI for Windows - otherwise opening PRs with improvements would not really make sense. ### What is your fix for the problem, implemented in this PR? This PR first makes it possible to run the test suite on Windows at all by "hiding" a bit of code behind `Gem.win_platform?` (`Spec::Manpages.setup` made it super complicated to run on Windows - and is not really necessary to run the test suite). It also works around a strange bug concerning `thor`'s (a vendored dependency) use of `readline` which crashes in strange ways on Windows (see #6902). And it adds applies a patch to the `readline` implementation used on CI (via RubyInstaller ruby) that otherwise blocks the tests (see #6907). Then it adds CI configuration for Azure Pipelines, a free for OSS CI platform. I configured the Azure Pipelines build to create a JUnit compatible report if the test suite and display it in the "Tests" tab of the build. ### Why did you choose this fix out of the possible options? I think disabling this code for Windows is a valid choice to get the ball rolling, later this will undone and the underlying problem will be fixed. I chose the workarounds for #6902 and #6907 as I couldn't find a proper bugfix yet - so this will be one of the things to be fixed using Windows CI. Azure Pipelines is a great CI platform for Windows (and later even multiple platforms if we choose to also run the tests on Linux and macOS). I chose not to adapt the `rake travis` task (yet) because it is _much_ more complex than the "simple" `bin/rspec` test suite run which I could directly execute in the CI scripts of Azure Pipelines. Co-authored-by: Jan Piotrowski <piotrowski+git@gmail.com> Co-authored-by: Jan Piotrowski <piotrowski+github@gmail.com>
| * manually install rspec_junit_formatterJan Piotrowski2019-02-111-1/+5
| |
| * always exit `ruby bin/rspec` with code 0Jan Piotrowski2019-02-111-1/+1
| |
| * remove added dependencyJan Piotrowski2019-02-101-1/+0
| |
| * Merge branch 'master' into cross_platform_ciJan Piotrowski2019-01-2841-318/+72
| |\
| * | patch readline in site_ruby (workaround for #6907)Jan Piotrowski2019-01-142-1/+46
| | |
View Lorry Controller Status