Combine grouping and separateMinorPatch - still getting two separate branches

[margau]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

Forgejo

Which version of Renovate are you using?

43.220.0

Please tell us more about your question or problem

Hi,
I have two relevant dependencies:

• copier with package name https://codeberg.org/margau/copier-python-uv.git
• docker, e.g. codeberg.org/margau/buildenv*

I wanna group together patch updates of copier and docker digest updates into the group housekeeping. Non-Patch-Updates of copier should stay separate.

Config Extract of the package rules:

    {
      "matchManagers": [
        "copier"
      ],
      "separateMinorPatch": true
    },
    {
      "matchUpdateTypes": [
        "patch",
        "digest"
      ],
      "matchPackageNames": ["codeberg.org/margau/buildenv*", "https://codeberg.org/margau/copier-python-uv.git"],
      "groupName": "housekeeping",
      "automerge": true,
      "automergeSchedule": "* 0-3 */2 * *"
    }

With that config, I get 2 separate MRs:
One for docker with the branch name renovate/housekeeping (e.g. https://codeberg.org/entropia/paperless-asn-qr-codes/pulls/139),
another one for copier with the branch name renovate/patch-housekeeping (e.g. https://codeberg.org/entropia/paperless-asn-qr-codes/pulls/140).

Expected would be a single PR/group.
What do I need to be able to have those in a single MR?

SeparateMinorPatch is necessary, as I wanna follow the patches (in the old minor branch) automatically, while manually looking over the the minor changes.

Thanks!

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[RenSolvyn]

I reproduced your exact split on Renovate 43.220.0 and then tested every plausible config counter to it; exactly one produces the single MR you want, and the others fail in instructive ways, so here is the verified fix first and the map of dead ends after it, since one of them is a config the validator outright rejects.

The fix, verified: add a branchName override to your housekeeping rule:

{
  "matchUpdateTypes": ["patch", "digest"],
  "matchPackageNames": ["codeberg.org/margau/buildenv*", "https://codeberg.org/margau/copier-python-uv.git"],
  "groupName": "housekeeping",
  "branchName": "{{{branchPrefix}}}housekeeping",
  "automerge": true,
  "automergeSchedule": "* 0-3 */2 * *"
}

Measured result on a minimal reproduction (details below): one branch, renovate/housekeeping, containing both the patch update and the second dependency's update together; the minor update remains on its own separate branch, so the part you called out as necessary, patches automerged while minors get manual review, is preserved exactly. The config validates clean. branchName is documented as an advanced field you normally should not touch, but scoped inside this single rule it is precise: it only rewrites the name for updates that already matched your housekeeping criteria.

How I verified it: your codeberg and docker datasources are not reachable from my test environment, so I built a manager-agnostic analog with npm: dependency A with separateMinorPatch: true via one rule (your copier rule), and a second rule grouping patch updates of A and B into housekeeping (your rule, with my B's patch standing in for your docker digest; the branch-naming layer under test is shared across managers). Running your rule shape produced your split verbatim: renovate/housekeeping (dep B) and renovate/patch-housekeeping (dep A's patch), the exact two branch names from your MRs 139 and 140.

The dead ends, all measured on 43.220.0, in case you try them or find them suggested elsewhere:

1. "separateMinorPatch": false inside the housekeeping rule (the obvious idea: your rule already matches only patch and digest, so switching it off there looks like it would strip the prefix without touching minors). Renovate rejects the config entirely: packageRules cannot combine both matchUpdateTypes and separateMinorPatch. The rule never runs.
2. "additionalBranchPrefix": "" in the housekeeping rule: no effect, branch set unchanged.
3. "branchTopic": "housekeeping" in the housekeeping rule: no effect.
4. "groupSlug": "housekeeping" explicitly: no effect, the branch is still renovate/patch-housekeeping.

Number 4 is the informative one: even an explicitly set group slug comes out prefixed, which means the patch- is prepended to the slug programmatically during update generation, after additionalBranchPrefix, branchTopic, and groupSlug have all resolved. I confirmed this in the 43.220.0 code itself; lib/workers/repository/updates/branch-name.ts contains (quoting the compiled line):

if (update.updateType === "patch" && update.separateMinorPatch)
    update.groupSlug = `patch-${update.groupSlug}`;

so the prefix lands on whatever slug you configured, explicit or not. That is why only a full branchName template, which is evaluated last and bypasses the slug machinery, can make the two update streams converge onto one branch. It is also, I would argue, why this feels unintuitive: the prefix is not reachable through any of the fields whose documented job is to shape the branch name.

One pragmatic footnote in case you prefer to avoid the branchName hammer entirely: your existing rule already applies automerge and the schedule to both of the split branches, so the two-MR state is operationally equivalent to the single-MR state, just noisier. The override above is for when the single MR is the point.

Hardening checks, since a config fix should survive more than its demo: with the override in place I additionally verified that a third dependency with an available patch update but outside matchPackageNames stays on its own branch (the override does not leak past the rule's match), that swapping the order of the two package rules changes nothing, that glob-style matchPackageNames (your buildenv* shape) behave identically, and that two different update types merge under the single branch (a patch and a minor converged into one renovate/housekeeping, which is the shape of your patch plus digest pairing). One warning that came out of deliberately breaking it: a typo inside the branchName template does not error, Handlebars just renders the unknown variable as empty, and you silently get a wrong branch name like housekeeping with no prefix. After deploying, glance at the branch name Renovate actually creates on the next run.

Scope note for honesty: the reproduction used the npm manager rather than copier and docker for the reachability reason above; the grouping and branch-naming layer is manager-independent, and the branch names matched yours character for character, but if your real setup behaves differently after adding the override, say so and I will dig further.