Group all renovate dependancies and lock file into one single MR

[juancarlosjr97]

How are you running Renovate?

Self-hosted

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

v35.112.1

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

gitlab.com

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

I never saw this working

Wanted end result.

We would like to have all changes update dependencies and lock file maintenance into a single MR.

What you tried so far.

We have self-hosted runners on GitLab and to avoid exhausting them, we have added the configuration as follows

groupName: "all dependencies",
separateMajorMinor: false,
groupSlug: "renovate-dependencies",
packageRules: [
  {
    matchPackagePatterns: ["*"],
    groupName: "all dependencies",
    groupSlug: "renovate-dependencies",
  },
],
lockFileMaintenance: {
  enabled: true,
  schedule: null,
},

To avoid creating multiple PRs all together as just one PR.

Relevant debug logs

Logs

Copy/paste the relevant log(s) here, between the starting and ending backticks

[rarkins]

Lock file maintenance in the same PR is not advised and will be deprecated in future

[rarkins]

It can be fine if you use matchUpdateTypes=lockFileMaintenance

[juancarlosjr97]

Would that group everything into a single MR? I just want to be grouped but if it is going to be deprecated, and it is not advised, then perhaps not doing it is the best way.

[juancarlosjr97]

I see I can put everything into the configuration such as "major, minor, patch, pin, pinDigest, digest, lockFileMaintenance, rollback, bump, replacement" and let the configuration handle it :)

[viceice]

lockfile maintenance and replacements can no longer be grouped in renovate v43

• fix!: prevent grouping of replacement updates #40758
• fix!: prevent grouping of lockfile maintenance updates #40781

[TiAlRo]

We would have liked to keep the possibility to group lock file maintenance and other updates in a single PR.

First, two PR at the same time lead to race conditions in the pipeline. One pipeline deploys a test deployment and before it can be tested, the other pipeline uninstalls the test deployment. Ofc this is not a clean pipeline setup which we should handle better anyway.

Second, even with clean pipeline setup, we would like to have auto-merge after a succeeding pipeline. I doubt this is possible when lock file maintenance and other updates are separated, but I have to test it.

[viceice]

no, because grouping them causes different troubles. that's the reason we did it.