Grouping minor and patch updates with bundler does not work

[andyundso]

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us what version of Renovate you run.

v36

If you're self-hosting Renovate, select which platform you are using.

github.com

Was this something which used to work for you, and then stopped?

It used to work, and then stopped

Describe the problem

For most of the project, we run a configuration like this:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "packageRules": [
    {
      "groupName": "all non-major dependencies",
      "groupSlug": "all-minor-patch",
      "matchPackagePatterns": [
        "*"
      ],
      "matchUpdateTypes": [
        "minor",
        "patch"
      ]
    }
  ],
  "rangeStrategy": "update-lockfile"
}

Basically, we group all minor and patch updates into one PR since those usually do not require a detailed look and can be merged straight forward.

In the last couple of months(?) we noted that Renovate sometimes reports that it will update something in its PR description in the Gemfile, but the resulting Git diff tells otherwise. Example:

Package	Type	Update	Change
appsignal (source, changelog)		patch	3.4.6 -> 3.4.10
caddy	final	minor	2.6.4 -> 2.7.2
carrierwave		patch	3.0.1 -> 3.0.2
mini_racer (changelog)		minor	0.6.4 -> 0.8.0
rexml		patch	3.2.5 -> 3.2.6
route_translator (changelog)		minor	13.1.1 -> 13.2.1
ruby (source)		minor	3.1.4 -> 3.2.2
ruby	final	minor	3.1.4-alpine -> 3.2.2-alpine
ruby	stage	minor	3.1.4-alpine -> 3.2.2-alpine
selenium-webdriver (source, changelog)		minor	4.10.0 -> 4.11.0
vite (source)	devDependencies	patch	^4.4.4 -> ^4.4.9
webdrivers (changelog)		minor	5.2.0 -> 5.3.1

---

Git diff of Gemfile.lock:

diff --git a/Gemfile.lock b/Gemfile.lock
index 7df3248..826c140 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -72,9 +72,9 @@ GEM
       i18n (>= 1.6, < 2)
       minitest (>= 5.1)
       tzinfo (~> 2.0)
-    addressable (2.8.4)
+    addressable (2.8.5)
       public_suffix (>= 2.0.2, < 6.0)
-    appsignal (3.4.6)
+    appsignal (3.4.10)
       rack
     attrtastic (0.4.3)
       actionpack (>= 3.0)
@@ -104,7 +104,7 @@ GEM
     capybara-screenshot (1.0.26)
       capybara (>= 1.0, < 4)
       launchy
-    carrierwave (3.0.1)
+    carrierwave (3.0.2)
       activemodel (>= 6.0.0)
       activesupport (>= 6.0.0)
       addressable (~> 2.6)
@@ -214,7 +214,7 @@ GEM
     mime-types-data (3.2023.0218.1)
     mini_magick (4.12.0)
     mini_mime (1.1.2)
-    mini_portile2 (2.8.2)
+    mini_portile2 (2.8.4)
     mini_racer (0.6.4)
       libv8-node (~> 16.19.0.0)
     minitest (5.19.0)
@@ -257,7 +257,7 @@ GEM
     puma (6.3.0)
       nio4r (~> 2.0)
     racc (1.7.1)
-    rack (2.2.7)
+    rack (2.2.8)
     rack-proxy (0.7.6)
       rack
     rack-test (2.1.0)
@@ -304,7 +304,7 @@ GEM
       mime-types (>= 1.16, < 4.0)
       netrc (~> 0.8)
     rest-graph (2.0.3)
-    rexml (3.2.5)
+    rexml (3.2.6)
     rouge (1.11.1)
     route_translator (13.1.1)
       actionpack (>= 5.2, < 7.1)
@@ -473,7 +473,7 @@ DEPENDENCIES
   xml-sitemap
 
 RUBY VERSION
-   ruby 3.1.4p223
+   ruby 3.2.2p53
 
 BUNDLED WITH
    2.4.12

Note that updates like for mini_racer or router_translator for the update are missing.

Looking into the debug logs, it seems that bundle is executed with --patch, which then does not do those minor updates mentioned.

2023-08-08T09:03:56.9836686Z DEBUG: Executing command (repository=xxx/xxx, branch=renovate/all-minor-patch)
2023-08-08T09:03:56.9837828Z        "command": "bundler lock --patch --strict --update appsignal carrierwave mini_racer rexml route_translator selenium-webdriver webdrivers"

I would assume this is because of #19446, but I have no idea how we could influence the mentioned updateType option to always be minor.

Minimal example: https://github.com/andyundso/renovate-group-minor-patch

Relevant debug logs

Mentioned above, happy to extend it if more content is needed.

Have you created a minimal reproduction repository?

I have linked to a minimal reproduction in the description above

[rarkins]

It looks like Renovate needs to update patch, minor and major updates separately, if more than one type exist in the same branch

[rarkins]

Yes, exact version pinning would avoid this problem. Worst case you'd get a PR with:

• Dependency updated in Gemfile as described in the PR
• An artifacts update error from bundler describing any incompatibilities which caused the error

[andyundso]

okay, would we also need to switch the updateStrategy? right now we are using update-lockfile, as recommended for bundler.

[rarkins]

You can/should leave it as default (i.e. do not configure it)

[HonkingGoose]

If I understand things right, this PR should fix the problem?

• fix(bundler): update patch, minor, major separately #23770

[rarkins]

It fixes it as much as is possible with rangeStrategy=update-lockfile

[andyundso]

I marked the PR as answer for now. There are still some edge-cases which do not work properly as I described above in this thread, but this is outside of the main issue I reported here and I need to first to do some experiments. Many thanks for the quick replies and fix!

[rarkins]

Workaround: pin bundler dependencies (exact versions instead of ranges)

[jume-dev]

So, I am still running into this issue besides having exact versions, see here for a minimal example repository https://github.com/jume-dev/renovate-group-minor-patch, and you can even see part of the error log in the PR jume-dev/renovate-group-minor-patch#2

What I found out was, that renovate tries to do execute bundler lock --patch --strict --update sequel puma rails faker but as sequel only is a minor update it breaks with an error that he can't find it on rubygems, which seems weird. Trying it out manually with bundler lock --minor ... or even skipping the updateType works.

[andyundso]

I made the same observation, as we are running exact versions for one test repository as well. I opened a discussion in the Rubygems repository about this. I'm sure there is a reason why bundler is unable to report certain version conflicts when applying a flag like --patch or --minor, but it's really confusing as an end-user.