Use config from non-default branch (No Forking)

[AlexanderFuergut]

How are you running Renovate?

Self-hosted

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

Most recent

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

Azure DevOps (dev.azure.com)

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

No response

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

I never saw this working

Wanted end result.

Have config changes (both config.js and renovate.json) on a branch (eg /new_renovate_feature) and run Renovate in our pipeline, so that it uses the config on the branch for that run instead of the config on the default branch.

What you tried so far.

Using baseBranches to set the baseBranch to the one with the config changes, but it doesn't use the config on the branch.
Using force in the config.js, but since config.js is also not being used from the branch it doesn't do anything.

Relevant debug logs

No response

[rarkins]

If you configure your config.js to use baseBranches=new_renovate_feature and useBaseBranchConfig=true then that might achieve what you're after

[AlexanderFuergut]

Thanks. The content of the config.js on the branch is ignored in favor of the base branch, so doing changes there has no effect.
What worked was setting the baseBranch as an environment var and setting the use base branch config as a runtime parameter with --use-base-branch-config=merge

[rarkins]

There is no such thing as config.js in a branch. config.js is server-side ("global") config, while in the repo you have "repo" config such as renovate.json. It sounds like you're putting the wrong config file in the repo

[AlexanderFuergut]

What do you mean there is no config.js in a branch and it is "server side"? I followed the Azure DevOps getting started article where a config.js is created in the top level of the repository together with pipeline.yaml, .npmrc and renovate.json files: https://docs.renovatebot.com/modules/platform/azure/

[rarkins]

If you choose to have config.js on a branch, you need to check out that branch before you run Renovate. Renovate won't notice or care which branch it's running in, or even whether or not it's running in a git repo.

Typically you don't run Renovate 1:1 in a repo (one config.js and one renovate.json per repo). Instead you should have a single repo with config.js which then renovates all other repos you want

[exoszajzbuk]

The issue is valid with renovate.json as well, or maybe it's just not clear for me how the "useBaseBranchConfig: merge` should work.

I have the following (basically empty) renovate.json on the main branch:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json"
}

I "extend" renovate.json on test-branch with the following:

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

so if I run renovate with the following env vars (a.k.a these would be in the central config.js):

    RENOVATE_USE_BASE_BRANCH_CONFIG: 'merge'
    RENOVATE_BASE_BRANCHES: '["test-branch"]'

then I can't see config:base getting applied, e.g. no "Dependecy Dashboard" issue is getting create. Or if I set renovate.json in the side branch test-branch to

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [":disableRenovate"]
}

I'd expect Renovate to be completely disabled "on that branch", but it isn't happening, it seems like the main branch config is taken into consideration in this case as well

[rarkins]

@RahulGautamSingh how close did you get to this in your "Reconfigure Renovate" PR work? e.g. being able to "simulate" the new run and describe changes?

[RahulGautamSingh]

Very close, to what you explain ie. simulate run & describ changes since we do extraction + lookup (branchifyUpgrades).

As pe above comment, I think:

1. dependencies that shouldn't be updated won't be. ✅
2. dependencies that should be updated will be. ✅
3. pull requests would be grouped how I want them to be -> (not tested)
4. files modified by post-upgrade commands are found correctly (i.e. are the fileFilters defined correctly) -> (not tested)

I will test the remaining two cases and update here.

[reduckted]

As a possible alternative, since I only want to test configuration changes, would using platform=local and checking out the repository on the specific branch manually be a suitable alternative?

So I've given this a try and it actually works quite well. I only have two complaints:

1. It logs warnings about not being able to sync branches because it's using the "local" platform. It would be nice if there was some way to suppress those warnings.
2. I have to use debug logging to find out what would be changed, but it sounds like the work @RahulGautamSingh is doing might solve that.

All in all, I'm pretty happy to use platform=local for testing/verifying config changes, because it's not something that I have to do very often.

@RahulGautamSingh Are the changes you're working on available somewhere? I'm interested in seeing what they are.

[RahulGautamSingh]

Here you go: #34696

[RahulGautamSingh]

Tested case 3: https://github.com/Rahul-renovate-testing/interactive-grouped/pull/3/files

Works well

Case 4, doesn't seem to be a possible case for the reconfigure pr logic as we do not go beyond branchifying the upgrades. wdyt? @rarkins