I'm sorry in advance if this is a duplicate. I tried searching for some keywords but nothing came up.
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.
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.
Switching the default branch to develop, which is not viable in our case.
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
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.
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:
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.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.
Thanks for the further ideas. I think it's maybe clear to me now:
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?
Yes, that's actually exactly how I imagined it to be, after reading your first comment.
That sounds perfect!
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.
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.
Most helpful comment
Thanks for the further ideas. I think it's maybe clear to me now:
So I'm thinking of an option
useBaseBranchConfigthat 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?