Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Restore Bundler 1 behavior regarding libraries & gemspecs
Up until the Bundler 2 upgrade, when in the context of updating a library, dependabot would first try locking the Ruby version according to the minimum ruby requirement specified in the gemspec (if any). If that fail, dependabot would retry without any ruby version locking by detecting a specific error message raised by Bundler. This feature was introduced by fcd5682. However, when the upgrade to Bundler 2 happened, the related spec started failing, because the string to look for within Bundler's error message was not updated to match what Bundler 2 was raising (error message was changed upstream at rubygems/bundler#6647). Instead, the spec was updated to match the new result (see dependabot#3319 (comment)). In the spec, dependabot is updating a Gemfile including ```ruby gem 'statesman', "~> 3.0.0" ``` in combination with a gemspec including ```ruby required_ruby_version ">= 1.9.3" ``` Statesman 3.0.0 has a Ruby ">= 2.2" requirement, so it does not support Ruby 1.9.3 already. The original dependabot behaviour was to ignore the preexisting mismatch and move on. That makes sense to me, there's some reasons why a library main have this situation. In my case, I have several Gemfiles testing different major versions of my dependencies (Rails, in particular), and some of them don't support the oldest Ruby supported by my gem (my Rails 7 gemfile does not support my oldest supported Ruby, 2.6). On a more pragmatic point of view, the old behavior didn't cause any reported issues that I know of, while the new behavior did bite my particular case. So this commit changes the expectation to what it used to be and updates the strings to look for in error messages to support both Bundler 1 and Bundler 2 error messages.
- Loading branch information