What's the future of "forking mode" for Renovate? #39263
Replies: 2 comments 5 replies
-
|
For us at GitLab it's a deal breaker. We've been running a fork of renovate for the last 5+ years which we added our own derivation of forkMode. That's how I ended up here, wanting to try and contribute something upstream so we can ditch our monkeypatched fork. Let me know if I can provide any additional context/information. Thanks |
Beta Was this translation helpful? Give feedback.
-
IntroRenovate should default to the safest behavior. This stops users doing unsafe things by accident. Fork mode is safer than direct accessYou say fork-mode is technically safer than plain Renovate:
I guess the reason Renovate defaults to direct access is because fork-mode was added later. Double down on fork mode instead of dropping it
Dropping fork mode is the wrong way to approach the maintenance problem. I suspect the problems with maintaining fork mode is partially because it gets less used and thus less attention. My fix is to move the bulk of the users and attention to the fork mode variant. If we must choose between fork-mode and direct access Renovate, keep fork mode and drop direct access Renovate. Proposal: swap apps aroundI propose swapping the apps around: fork-mode Renovate becomes plain Renovate. What's currently Renovate goes into a new "direct-access Renovate" app. The old fork-mode app is deprecated after suitable notice and time. The bulk of users probably stay on the now safer Renovate, those who want to live dangerously can opt-in to the "direct-access Renovate" app. You'll still have two branches to maintain though...I suspect you'll always want/need to support the now default fork mode and the separate "direct access Renovate" app though. Drawbacks of fork modeAccording to the Renovate docs the drawbacks of using Fork-mode are:
For me those drawbacks are no big deal, I don't use automerge in the first place, and my projects have a stable Can we improve fork-mode Renovate?I suspect the automerge limitation will always stay, due to the way "outsider Pull Requests" are treated as potentially unsafe by Git-hosting platforms. But is the no I'm asking because if you could make fork-mode Renovate more like plain Renovate, you would have less differences between the apps. Less difference means easier to maintain. OutroTo summarize: what's now Renovate will use fork-mode by default, move direct access stuff to separate app, migrate users from old fork-mode app to plain Renovate. As always you as maintainer have final say over what you choose to maintain, and what to drop. 😉 |
Beta Was this translation helpful? Give feedback.
-
Great idea!
Nor should there be. It would completely defeat the purpose of using the safe "fork mode" as it would allow potentially dangerous packages through? |
Beta Was this translation helpful? Give feedback.
-
|
I highly depend on auto merge, otherwise I'm no longer able to maintain so many projects |
Beta Was this translation helpful? Give feedback.
-
I would agree that we should try and provide both as well-supported models - not saying that we drop "direct" access
I agree that Renovate should be trying to provide the most secure option, by default. We may be able to nudge more folks towards Forking Renovate (on the Mend hosted side) - this isn't a commitment that we'll do it, or "swap the apps", but something I can take away and see what makes sense For the CLI, if we did decide to do so, this would be in the next major version, where we'd add a new configuration item |
Beta Was this translation helpful? Give feedback.
-
Can you explain why you use fork mode if it isn't for security? |
Beta Was this translation helpful? Give feedback.
-
|
I don't use fork mode because I need auto merge. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Tell us more.
Renovate (at least on
platform=github) has a capability to run in "forking mode".This means that instead of Renovate pushing branches + PRs to the repository, it creates a fork of the repository, and pushes branches to the fork, then creates a PR in the upstream repository.
For example, compare:
Benefits of Forking Mode
As noted in https://docs.renovatebot.com/getting-started/running/#forking-renovate-app there are benefits to running Renovate in "forking mode", namely security:
Readaccess to the upstream repositoryIf we invert this, we can see that:
Writeaccess, which gives access to secrets in CI buildsAt some organisations, the ability for Renovate to push directly to branches is not wanted, and so having "fork mode" available is a big positive to supply chain security.
Compare this to the GitHub-native Dependabot, where GitHub Actions has a separate "Dependabot Secrets" to allow Dependabot to push branches that will run with a different context of secrets.
Having "fork mode" available is a key positive for these organisations.
The Mend-hosted "Forking Renovate" is installed on ~1k organisations (compared to ~65k organisations for non-forking) and ~30k repos (compared to ~2000k)
Why are we questioning the "future" of it + what are we hoping to achieve with this Discussion?
On the other hand, the workflow (and underlying code) adds complexity to the Renovate codebase.
Before considering #840, we want to understand whether the pros outweigh the cons, and what we can do to improve the maintainability of Renovate while providing strong supply chain security practices for users.
Examples
Configuration of reference:
forkTokenforkOrgforkCreationBeta Was this translation helpful? Give feedback.
All reactions