Can forking-renovate target a branch other than the default one?

[simonbasle]

We're dealing with multiple maintenance branches, and the default branch represents the latest production code.
Most of the time, when a fix makes sense in several maintenance versions, we implement it in the "older" relevant maintenance branch then forward-merge the fix in newer branches.

As a consequence, it makes sense for Renovate to propose upgrades in the oldest active maintenance branch, even though the repo's default branch is different.

But we use the forking-renovate variant of the GitHub App.

Can you confirm that this scenario is possible ? (ie. can we configure forking-renovate to target a branch that is NOT the repository's default branch).

Asking because the drawbacks section of the doc mentions that it doesn't support the baseBranches option.

[simonbasle]

actually, the documentation of baseBranches here is pretty clear.
is there a chance it can be made to work on a single non-default branch at least, or is there a deeper limitation to the forking mode that prevents it from running on any other branch than the repository's default branch?

[rarkins]

What's your reason/restriction for using forking renovate?

[simonbasle]

principle of least privilege. the main app requires way too much write-level permissions for our taste (especially given we don't need automerge at all)

[rarkins]

Don't you think that GitHub's branch protection capabilities are adequate these days? You would need for both Renovate to go wrong as well as GitHub protections to fail, before something actually problematic happened

[simonbasle]

IIRC last time I checked the app was requesting "contents" write access, and github documentation lists a bunch of permissions here, including https://docs.github.com/en/rest/reference/branches#add-app-access-restrictions. wouldn't this enable the app to allow itself to bypass branch protection?

[rarkins]

No, contents write access just means it can create a branch. If you restrict who can merge to main branch then apps cannot overwrite that - you'd need to explicitly allow them. Then Renovate is like a contributor in the repo - not admin.

[janhoy]

Just became aware of the limitation for fork-mode and baseBranches. I'm willing to stand up a totally separate github workflow with a separate config for targeting my foo_branch. But is there some known workaround/hack that allows Renovate to work on and sync the non-default branch? E.g. I see there is an option to set forkCreation=false, documented as

Usually you will need to keep this as the default true, and only set to false if you have some out of band process to handle the creation of forks.

Would it be possible for us to use this setting in combination with a custom bash script that would handle syncing of foo_branch in the forked repo of our bot, so that when renovate is launched afterwards, the fork is there, already synced? But what combination of settings would I need for this? Guess the only way to tell renovate what branch to target for PRs is the baseBranches setting?

Cross-referencing #28700 and #7850

[rarkins]

There is no way to achieve this. The reason is that:

• To work properly, each base branch in the fork must be up to date with the same branch in the origin, before Renovate starts detecting dependencies
• The only way Renovate does this today is to use a REST API on github.com (not using git) and it's done for the default branch only, before the regular Renovate logic starts