Renovate EE - Configuration considerations when skipping onboarding

There are occasions when it’s desirable to have centralized control of the Renovate configuration used by onboarded repositories without requiring a config file in each individual repository. This is done by allowing Renovate to process repositories that don’t have a renovate.json configuration file.

It’s possible to skip onboarding of repositories using configuration at a global level by adding the following to your config.js configuration mounted via a Helm ConfigMap (or via environment variables):

"onboarding" : false,
"requireConfig" : "optional"

This causes Renovate to stop creating onboarding PRs for newly created repositories and allow the processing of repositories with or without a renovate.json configuration file. In other words, repositories run automatically without a config or onboarding being necessary, but it’s also possible to add a config to any repo if desired.

In this scenario, the effective configuration applied when processing a repository will be as follows (top to bottom). Settings on each layer override those on the layer above.

Renovate settings can be added to config.js as needed. However, there are circumstances in which you may want to control configuration settings at the SCM’s organization’s level, particularly repository-level configuration settings. Reasons include:

• Providing better visibility to repository users about the shared config defaults in use (they can be in a public repository), and

• Achieving different defaults per-org (for enterprises with multiple orgs)

This can be achieved by activating inherited configuration in config.js as shown here (or via environment variables):

“inheritConfig” : true

When this feature is enabled, the default behavior is for Renovate to look in the {{parentOrg}}/renovate-config repository for a configuration file named org-inherited-config.json. In this case, the effective configuration applied when processing a repository is as follows:

The configuration file name and repository name can be configured to different values via inheritConfigFileName and inheritConfigRepoName

If you are already taking advantage of custom presets and want to make use of those in repositories that don’t have a config file, you can extend from them in the org-inherited-config.json file. The example below extends from the {{parentOrg}}/renovate-config repo without explicitly indicating a preset name. This will tell Renovate to look for a default.json preset file located in that repository.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["local>{{parentOrg}}/renovate-config"]
}

Replace {{parentOrg}} with the name of the parent SCM organization.

To extend from a different preset in the same SCM endpoint, use "local>{{parentOrg}}/{{repoName}}:{{presetName}}"

In this scenario, the effective configuration applied when processing a repository is as follows:

Note how “settings from default.json (or named) preset file” is not placed below “settings in org-inherited-config.json" in the effective configuration flow. This is because preset settings via "extends" are resolved first and can be overridden if the same setting is used in the same configuration file (org-inherited-config.json config file in this case). See here for details.

Conclusion

When skipping onboarding, repositories don’t need a Renovate configuration file of their own; nevertheless, you have the flexibility to define their configuration with a combination of global, organization-level, and custom preset layers.

It is generally recommended to use presets or inherited configurations to define repository-level settings while leaving global configuration settings at the config.js or environment variable level. This allows the possibility of making repository-level configuration settings visible to repository owners, which can help them better understand why Renovate behaves in a given way while processing their repos.