Read configuration from the branch(es) in baseBranches

[sharkykh]

I'm sorry in advance if this is a duplicate. I tried searching for some keywords but nothing came up.

What would you like Renovate to be able to do?

Read renovate.json configuration from the branch(es) in baseBranches instead of the repository's default branch, so changes in baseBranches are applied instantaneously.

At pymedusa/Medusa we have two "main" branches: master and develop.
master is the repo's default branch
develop is used for development and is the single branch listed under baseBranches on the renovate.json config file.
(We use the GitHub app if that matters)

When we change the renovate configuration we have to wait until the next release to master in order for the changes to be applied.

Describe the solution you'd like

Would it be possible, to have a config option to "tell" the renovate bot to read the configuration (sans-baseBranches and other "risky" options?) from the baseBranch that is configured on the default branch?
So when it is enabled, the bot will consider the configuration defined in renovate.json on the baseBranch it is creating the dependency update branch and PR.

So for example,
if the default branch's renovate.json currently doesn't contain a labels property,
but the baseBranch's renovate.json contains "labels": ["update dep"] - it should apply the label to the PR being opened against that baseBranch.

Describe alternatives you've considered

Switching the default branch to develop, which is not viable in our case.

Additional context

N/A

---

We've been using the renovate GitHub app in our Python+JS project for two months now and we're very pleased! Thank you for this amazing service and support!
/cc @OmgImAlexis

[rarkins]

Thanks, this is not a duplicate.

The most important thing to decide is how the second configuration overrides the one in master. e.g. should it be cascading (you combine master and the other branch) or should the other branch have a complete/whole config of its own and you ignore everything in master except baseBranches?

Let's say that the other branch is called next and you plan to merge it into master later. That means you would also merge renovate.json too, in which case it would make sense that the config in next is a "complete" config rather than partial.

[sharkykh]

As for the example, I agree it would be the complete config rather than a partial in that case.

And as for the types of overrides:
I guess it ultimately depends on the repository's branching structure and workflow.

If a repository only has a single base branch listed, it is rather simple:
Assuming the default branch is master and baseBranches is ["next"],
then next will most likely be merged into master at one point or another.
So, a renovate.json file on next should completely override the one on master.

If a repository has multiple baseBranches,
I could kind of see uses for both config override options:

• Complete override:
  If the base branches are diverged in such a way that they won't be merged,
  python/cpython*, for example, has specific version branches and master being the "next version" branch, I can see how completely overriding the master config on each base branch makes sense - each version has its own dependencies, version constraints, PR title prefixes, etc.
  _{*Repository doesn't use renovate, it's just the first example that comes to mind.}
• Cascading/merge override:
  If the default branch contains a basic renovate configuration, and each base branch contains a configuration that extends it.
  I'm having a hard time coming up with a real life scenario for this, but it's possible someone out there would benefit from that kind of feature.

Of course I guess it's also possible to make it configurable for each base branch, rather than a "global" setting for enabling it on all the base branches.
This configuration should be exclusively defined by the configuration on the repo's default branch.
Meaning, just like baseBranches property, it won't get overridden by the values on the baseBranches.

[rarkins]

Thanks for the further ideas. I think it's maybe clear to me now:

• Our default should be existing behaviour, i.e. ignore baseBranch config
• We need an option now for completely override using baseBranch config
• Plan ahead for cascading/merged config in future if anyone needs it

So I'm thinking of an option useBaseBranchConfig that defaults to "none" (existing behaviour) and adding a new option "replace" for now, and leave unimplemented a "merge" option for future.

Do you think that satisfies your requirements?

[sharkykh]

Yes, that's actually exactly how I imagined it to be, after reading your first comment.
That sounds perfect!

[kuzm1ch]

Is there any update on this issue? In any case, it will be a very useful option for testing renovate config before merging it to the default branch.

[fullstackzach]

I think this would be useful for some of our projects too. They have a development baseBranch and we would prefer to have renovate read the renovate.json from that branch instead of master.

[languitar]

Another perspective why this could be helpful: I'd like to dry run renovate in merge requests changing the renovate.json to be sure that everything works as expected. This is currently impossible because the config from the merge request is never used by renovate.

[olegkrivtsov]

I'd like to take this one.

[olegkrivtsov]

My plan for implementing this:

1. Edit lib/config/options/index.ts and add another option useBaseBranchConfig, e.g.:

{
    name: 'useBaseBranchConfig',
    description: 'Read configuration from branches in baseBranches instead of main branch',
    type: 'string',
    allowedValues: ['none', 'replace'],
    default: 'none',
  },

2. Edit the documentation and describe the new option:

https://github.com/renovatebot/renovate/blob/main/docs/usage/configuration-options.md

3. I spent some time researching the code and deciding what would be the best place to override the branch config, and I guess it is the getBaseBranchConfig() function:

renovate/lib/workers/repository/process/index.ts

Lines 12 to 23 in 8e377e8

	function getBaseBranchConfig(
	baseBranch: string,
	config: RenovateConfig
	): RenovateConfig {
	logger.debug(`baseBranch: ${baseBranch}`);
	const baseBranchConfig = mergeChildConfig(config, { baseBranch });
	if (config.baseBranches.length > 1) {
	baseBranchConfig.branchPrefix += `${baseBranch}-`;
	baseBranchConfig.hasBaseBranches = true;
	}
	return baseBranchConfig;
	}

Check if we have useBaseBranchConfig option and it is equal to replace:

3.1. Checkout the base branch.
3.2. Load repository config from it (use getRepositoryConfig() function from lib/workers/global/index.ts).
3.3. Merge it with the global config (which is common for all base branches).
3.4. Return the resulting base branch config and use it further.
3.5. Maybe cache the result somehow to avioid continuous checkouts of the same branch.

Could you please let me know if this is a suitable plan?

[rarkins]

I think it might be easier if you restricted this feature to working with the same file name in the base branches as in the default branch. That way you could use platform.getJsonFile() although once you extend it to support branchName as a param.

[renovate-release]

🎉 This issue has been resolved in version 31.38.0 🎉

The release is available on:

• GitHub release
• 31.38.0

Your semantic-release bot 📦🚀