Bundler - lock update fails when using complex ranges in Gemfile

[chaadow]

What Renovate type are you using?

I'm using renovate as a scheduled pipeline on a self hosted gitlab instance using a renovate docker image (renovate/ruby:2.6.5)

renovate version: 19.89.1
Describe the bug
Hi, I have ranges in my Gemfile like so :
gem 'sidekiq', '~> 5.2', '>= 5.2.5'
However bundle lock --update fails with this error:

Could not find gem 'sidekiq (~> 5.2, >= 6.0.4)

(basically, it changes the right side)
Is it expected? should i change my Gemfile to not use ranges?

For exacts versions or ~> x.x.x it works, only issue is with ranges.

Did you see anything helpful in debug logs?

DEBUG: findPr(renovate/major-all, Update dependency sidekiq to v6, !open) (repository=kc/new-auth-api, dependencies=sidekiq, branch=renovate/major-all)
DEBUG: prAlreadyExisted=false (repository=kc/new-auth-api, dependencies=sidekiq, branch=renovate/major-all)
DEBUG: Checking schedule(at any time, null) (repository=kc/new-auth-api, dependencies=sidekiq, branch=renovate/major-all)
DEBUG: No schedule defined (repository=kc/new-auth-api, dependencies=sidekiq, branch=renovate/major-all)
 INFO: Branch needs creating (repository=kc/new-auth-api, dependencies=sidekiq, branch=renovate/major-all)
DEBUG: Using parentBranch: undefined (repository=kc/new-auth-api, dependencies=sidekiq, branch=renovate/major-all)
DEBUG: manager.getUpdatedPackageFiles() (repository=kc/new-auth-api, dependencies=sidekiq, branch=renovate/major-all)
DEBUG: Updating packageFile content (repository=kc/new-auth-api, dependencies=sidekiq, branch=renovate/major-all)
DEBUG: bundler.updateArtifacts(Gemfile) (repository=kc/new-auth-api, dependencies=sidekiq, branch=renovate/major-all)
 INFO: Running bundler via global bundler (repository=kc/new-auth-api, dependencies=sidekiq, branch=renovate/major-all)
DEBUG: bundler command (repository=kc/new-auth-api, dependencies=sidekiq, branch=renovate/major-all)
       "cmd": "bundle lock --update sidekiq"
 WARN: Unknown bundler lock file update error (repository=kc/new-auth-api, dependencies=sidekiq, branch=renovate/major-all)
       "err": {
         "killed": false,
         "code": 7,
         "signal": null,
         "cmd": "bundle lock --update sidekiq",
         "stdout": "Fetching gem metadata from https://rubygems.org/.........\nFetching gem metadata from https://rubygems.org/.\n",
         "stderr": "The dependency tzinfo-data (>= 0) will be unused by any of the platforms Bundler is installing for. Bundler is installing for ruby but the dependency is only for x86-mingw32, x86-mswin32, x64-mingw32, java. To add those platforms to the bundle, run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`.\nCould not find gem 'sidekiq (~> 5.2, >= 6.0.4)' in any of the gem sources listed\nin your Gemfile.\n",
         "message": "Command failed: bundle lock --update sidekiq\nThe dependency tzinfo-data (>= 0) will be unused by any of the platforms Bundler is installing for. Bundler is installing for ruby but the dependency is only for x86-mingw32, x86-mswin32, x64-mingw32, java. To add those platforms to the bundle, run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`.\nCould not find gem 'sidekiq (~> 5.2, >= 6.0.4)' in any of the gem sources listed\nin your Gemfile.\n",
         "stack": "Error: Command failed: bundle lock --update sidekiq\nThe dependency tzinfo-data (>= 0) will be unused by any of the platforms Bundler is installing for. Bundler is installing for ruby but the dependency is only for x86-mingw32, x86-mswin32, x64-mingw32, java. To add those platforms to the bundle, run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`.\nCould not find gem 'sidekiq (~> 5.2, >= 6.0.4)' in any of the gem sources listed\nin your Gemfile.\n\n    at ChildProcess.exithandler (child_process.js:295:12)\n    at ChildProcess.emit (events.js:210:5)\n    at ChildProcess.EventEmitter.emit (domain.js:478:20)\n    at maybeClose (internal/child_process.js:1023:16)\n    at Process.ChildProcess._handle.onexit (internal/child_process.js:281:5)"
       }
DEBUG: branchPrefix: renovate/ (repository=kc/new-auth-api)
DEBUG: Found 0 Renovate PRs (repository=kc/new-auth-api)
       "renovatePrs": []
DEBUG: Removing any stale branches (repository=kc/new-auth-api)
DEBUG: config.repoIsOnboarded=true (repository=kc/new-auth-api)
DEBUG: No renovate branches found (repository=kc/new-auth-api)
DEBUG: ensureIssueClosing() (repository=kc/new-auth-api)
 INFO: Finished repository (repository=kc/new-auth-api)

To Reproduce

Additional context
Here is the renovate.json of the ruby repository:

{
  "extends": [
    "config:base"
  ],
  "groupName": "all",
  "prHourlyLimit": 2,
  "prConcurrentLimit": 5,
  "ignorePaths": [
    "docs/**/*"
  ]
}

And here is the renovate config.js

module.exports = {
  platform: 'gitlab',
  endpoint: 'http://gitlab.koba-civique.com/api/v4/',
  token: process.env.RENOVATE_TOKEN,

  repositories: [
    'kc/backoffice-api',
    'kc/workspace',
    'kc/new-auth-api'
  ],

  logLevel: 'info',
  bundler: { "enabled": true },

  requireConfig: true,
  onboarding: true,
  onboardingConfig: {
    extends: ['config:base'],
    prHourlyLimit: 2,
    prConcurrentLimit: 5,
    ignorePaths: ['docs/**/*'],
    separateMinorPatch: false,
    separateMajorMinor: false,
    separateMultipleMajor: false

  },
  enabledManagers: [
    'bundler'
  ]
};

[chaadow]

I've also noticed many gems in my Gemfile not getting updated thanks to bundler-audit, including puma I guess I will change to follow this convention ~> x.x.x for now until this is further investigated.

[rarkins]

This particular syntax is confusing Renovate. It's expecting the second part to be limiting the first part like <= or <. I guess you'd want the update to be ~> 6.0 ?

[chaadow]

@rarkins Usually the second part is to ensure some patch version including a "bug fix" or "security fix" be installed in the project.

for this case gem 'sidekiq', '~> 5.2', '>= 5.2.5', The ideal solution would be (IMHO):

• if there is a new patch version: gem 'sidekiq', '~> 5.2', '>= 5.2.6' ( or gem 'sidekiq', '~> 5.2.6')
• if there is a new minor version: gem 'sidekiq', '~> 5.3.0'
• if there is a new major version gem 'sidekiq', '~> 6.0.0' (same as the "minor" case)

I think this will be compatible with existing Gemfiles, while smoothly transitioning to the renovate way

[chaadow]

I think with using a tool like renovate to upgrade dependecies, this form ~> x.x.x is a good compromise and wouldn't mind updating my Gemfile to follow this convention, maybe I'd suggest explicitly add not to use complex ranges in the docs.

[chaadow]

For completion sake, as I was scanning through my Gemfile for different gem "declarations", I've just noticed that renovate does not detect this case as well:
gem 'rubocop-rails', '~> 2.3', require: false
(currently there is a 2.4.0 version)

I think that's because there is no patch version specified, so it's confused. ( The require: false is not to be taken into consideration as it works for another case for me: gem 'rubocop', '~> 0.78.0', require: false)

[rarkins]

Renovate doesn’t upgrade if the new version satisfies the existing range. If you need ranges then keep them wide. I’d you don’t need them then pin them instead and let Renovate keep it updated.

[rarkins]

And if your repo is an app, just use exact versions

[chaadow]

Renovate doesn’t upgrade if the new version satisfies the existing range. If you need ranges then keep them wide. I’d you don’t need them then pin them instead and let Renovate keep it updated.

That's what I was saying, if someone uses renovate, no need to keep wide wide ranges. I'm just pointing out that many Gemfiles out there have different semantic versionning strategies, developers may declare gems in different ways.

The fact still remains that this form is quite popular in Gemfiles: gem 'sidekiq', '~> 5.2', '>= 5.2.5'

All I'm saying is, if possible, you can add in the docs what are the forms that are accepted/handled by renovate, because I was having gems that were being updated, and some that weren't (So I was thinking everything was working OK) and wasn't aware of that.

(For instance there was a CVE for puma considered as high) and as I said as I'm implementing bundler-audit for security purposes, I've discovered it. I guess some people might be in my situation.

[chaadow]

And if your repo is an app, just use exact versions

For instance, you can point to users that if their repo is an app, and they want to use renovate to handle updates, they should stick to exact versions, and let renovate handle all the PR/MR upgrade, while also pointing out that ~> x.x.x is supported without complex range.

Because right now if many gem declaration patterns are used for big gemfiles, people might think that everything works without checking the cron or scheduled pipeline everytime, and many upgrades/updates can go unnoticed

[rarkins]

We will soon support updating the lock file only, so people will get the PRs they expect. If they decide they also want the Gemfile ranges updates too, then they can consider which is the best config. I agree with you that the current approach is suboptimal as people may have mixed expectations.

[chaadow]

Another argument: Most ruby developers copy the line to add to their gemfiles from rubygems.org
and for some gems like this one

They suggest to add: gem 'algoliasearch-rails', '~> 1.23', '>= 1.23.2' instead of 'algoliasearch-rails', '~> 1.23.2'

Just saying that this is a popular form of gem declaration and it might be good to say here in the docs that only the aforementioned patterns are currently supported.

[rarkins]

Yes, good point. It’s essentially the long way to replicate npm’s ^1.23.2 semantics. Ideally Bundler would add first class support for it but until then we should recognise this common declaration pattern.

[rarkins]

I've added a failing test case to this branch: https://github.com/renovatebot/renovate/tree/fix/5050-bundler-update-complex

[renovate-release]

🎉 This issue has been resolved in version 19.96.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀