Use hybrid autodiscoverFilter + App-install fence for multi-account Renovate governance
Date: 2026-06-15 Status: Accepted Decision: hl-cujh Deciders: @seanb4t
Context
Section titled “Context”Renovate CE is being expanded from one account (fzymgc-house) to three (adding seanb4t and holomush) from a single in-cluster deployment. A governance model is needed to decide which repositories CE manages, without per-account deployments. The seanb4t account has 49 source repos plus 77 forks; the forks must never receive PRs, and membership for the personal account should be curated. A single control mechanism is insufficient: autodiscoverFilter alone cannot gate per-repo membership within an account, and App install scope alone provides no outer boundary against future account sprawl (and its “Selected repositories” default flips forkProcessing to enabled).
Decision
Section titled “Decision”Adopt a three-layer defense-in-depth governance model: (1) mendRnvAutoDiscoverFilter as an account-level OUTER FENCE scoped to fzymgc-house/*,seanb4t/*,holomush/*; (2) GitHub App install scope as the per-repo INNER GATE — org-wide for fzymgc-house and holomush, “Selected repositories” for seanb4t; (3) onboarding PRs as the final opt-in gate, so no repo becomes managed without an explicit human merge.
Rationale
Section titled “Rationale”- The 77 seanb4t forks make broad autodiscovery unsafe; Selected install prevents surfacing them even if the forkProcessing guard were bypassed.
- autodiscoverFilter is a global-only operator control repos cannot override, making it a reliable outer boundary.
- Onboarding PRs ensure no repo transitions to managed state silently.
- Three independent layers mean no single misconfiguration causes a fork-onboarding flood.
Alternatives Considered
Section titled “Alternatives Considered”- autodiscoverFilter-only glob fence (rejected): simple and fully git-tracked, but cannot enforce per-repo membership within an account — every repo matching the account glob becomes visible.
- App install scope only (rejected): GitHub-native per-repo gating, but no outer fence against future account sprawl, and “Selected” install sets forkProcessing default to enabled (fork onboarding risk).
- Hybrid fence + gate + onboarding PR (chosen): three independent layers must all pass; outer fence caps account scope, inner gate caps per-repo scope for the personal account, onboarding PR prevents silent management.
Consequences
Section titled “Consequences”- Positive: fork-onboarding risk is near-zero under normal operation; adding a fourth account later needs only a filter widening plus an App install — no architectural change; each layer is independently auditable (git config, GitHub App UI, PR history).
- Negative: App install scope is not git-tracked, so rollout requires manual GitHub UI coordination per account; the three-layer model adds conceptual surface area future operators must understand.
- Neutral:
forkProcessing: "disabled"adds a fourth guard but is a per-repo-overridable config default, not architecturally load-bearing on its own.