Provide capability to use multiple configuration files for monorepos

[tomkerkhove]

What would you like Renovate to be able to do?

Provide capability to use multiple configuration files for monorepos, so that per component we can have a Renovate configuration to keep them small and scoped.

While re-usable presets can help; top-level configuration such as includePaths is not supported.

Originates from #19666.

If you have any ideas on how this should be implemented, please tell us here.

N/A

Is this a feature you are interested in implementing yourself?

No

[viceice]

unlikely to happen

[rarkins]

I'm not sure how this would even work. More details needed

[tomkerkhove]

So here is what we have now and is not really working:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "One/repo//Automation/Renovate/config/renovate.component-a",
    "One/repo//Automation/Renovate/config/renovate.component-b"
  ]
}

These are respective configurations for a single component in a mono-repo and is tailored to that repo. Some examples are top-level configuration options such as branchPrefix, labels, commitMessageSuffix, enabledManagers & includePaths.

When running the above, I'm seeing that Renovate will use the top-level configuration from component-b and ignore component-a, which is probably by design? Is there a way that it just runs both in parallel?

In theory, I could move includePaths et al to package rules but that introduces a lot of duplication.

I was hoping to copy over the appropriate configuration to renovate.json but it looks like Renovate is doing a full clone of the repo so that is not working either. Or is there a way to avoid cloning the repo and run in current folder? I see the folders are documented but likely it will be overridden anyway

[tomkerkhove]

I'm not a TS/JS expert, but it is currently ran by using npx --userconfig .npmrc renovate and was wondering if we could add a configuration similar to --config <path>.

[rarkins]

Renovate operates on multiple repos per run. If you want a different global config like your example then you can already do that

[tomkerkhove]

Just to be clear - I'm asking for a self-hosted scenario.

But that's what I figured; I'm curious to know how it is running them? Imagine I have 1 repo with 2 configs; how do I tell it to use config A and not B?

[viceice]

no, not possible.

[tomkerkhove]

That's fine, but has this been taken in to consideration?

[viceice]

no, doesn't fit to renovate workflow

[tomkerkhove]

It does for self-hosted scenario.

[viceice]

i mean it doesn't fit to current internal renovate architecture.

[rarkins]

Converted to a discussion

[gberche-orange]

My team is meeting similar challenges with a single renovate.json5 file configured into our mono repo:

• the renovate.json5 file is now 350 lines long and hard to navigate
• git conflicts occur with multiple contributions to the same file
• with many uses of regexp manager, it is common for a given dependency to require changes to the packageRules and regexManagers, which become long, without a clear sorting order

As I understand github hosted presets from https://docs.renovatebot.com/config-presets/#github-hosted-presets , extracting parts of configuration from our github>org/repo:renovate.json5 into github>org/repo:component1.json5 and github>org/repo:component2.json5 has the following drawbacks for the usage of mend bot on github:

• the "extends": ["github>org/repo:component1.json5"] needs to be modified in each clone, or minimal reproduction repos to point to the local repo
• requires explicitly listing every component

The modularity issue in configuration seems a common problem to many systems. This might offer inspiration and reuse for renovate ?

For instance, K8S and kustomize use strategic-merge-patch or Json patches, see https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/patches/

This enables granular fine-grain, focussed files contributing to constructing a single large (json) document.

Could renovate support similar patches applying on the current single configuration file ?

[tomkerkhove]

Our main struggle is that not everything is supported when using backend/renovate.json & frontend/renovate.json approach. In terms of switching is also not an alternative for us, we tried to use that route but renovate always clones the repo and instantly runs so you cannot rename files or so.

[gberche-orange]

I'm rather looking for the ability for a renovate.json to include e.g. backend/renovate.json and frontend/renovate.json. In my particular use-case, this would rather be worded as type of artefacts such as bosh-releases.json5 (for bosh releases) bosh-stemcells.json5, crossplane.json5, vendir.json5 etc...

Ideally, the top renovate.json5 could include a regexp of files to load from so that the addition of a new file does not require modification of the root renovate5.json

Regarding conflicts, documented precedence rules would indicate what to expect when loading the additional files. Also the renovate dashboard would have debug traces displaying the resulting final configuration.

[Memfisrain]

@rarkins Hey, we're in the process of researching a solution for automatic dependency update for our company and renovate looks pretty solid and configurable solution.

Could you update on the status of the question above, like the situation when we have a monorepo with frontend and backend packages and would like to include backend/renovate.json and frontend/renovate.json.

Anyway, thanks for the great product.

[rarkins]

A simple includes could be achieved today with "local>" presets pointing to the same repo. Anything advanced isn't planned unless a Mend.io enterprise customer needs it.

[Memfisrain]

got it, thanks!