Use inline config.js baseline over a shared preset repo for Renovate policy
Date: 2026-06-15 Status: Accepted Decision: hl-6fu4 Deciders: @seanb4t
Context
Section titled “Context”Renovate CE global policy (baseline presets, fork guard, manager set, automerge tiers, dependency dashboard) must be authored somewhere now that CE serves three accounts. The prior state was an empty config.js stub (onboarding rode stock config:recommended). Two homes were possible: an inline config.js delivered via the chart’s renovate.config Helm value (git-tracked in the cluster repo, flows down as global defaults), or a separate GitHub-hosted preset repo (github>fzymgc-house/renovate-config) that every managed repo extends.
Decision
Section titled “Decision”Author the Renovate global policy as an INLINE config.js baseline shipped through the chart’s renovate.config Helm value (rendered to ConfigMap renovate-ce-config-js, mounted /usr/src/app/config.js), explicitly rejecting a shared preset repository. The global config.js carries only the GENERIC, account-agnostic baseline; cluster-specific rules (component-family groups, per-manager file patterns) remain in selfhosted-cluster/.github/renovate.json, which overrides the global baseline for that repo.
Rationale
Section titled “Rationale”- Inline config.js keeps the policy-change workflow identical to all other infra: cluster-repo PR + ArgoCD sync, fully auditable and revertible.
- Global defaults flow down to every discovered repo automatically — no per-repo
extendsopt-in, reducing onboarding friction. - No runtime dependency on an external GitHub-hosted preset repo (one fewer network failure mode and one fewer repo to self-manage).
- The DRY wrinkle (baseline echoed in the cluster repo’s own renovate.json) is accepted as a conscious tradeoff; plan-level alignment keeps drift manageable.
Alternatives Considered
Section titled “Alternatives Considered”- Shared preset repo
github>fzymgc-house/renovate-config(rejected): single DRY source, repos extend it directly, preset edits apply without a cluster-repo PR — but requires creating and maintaining an extra public repo, makes policy opt-in per repo (mustextends) rather than default-down, and adds a runtime GitHub dependency. Remains on the Out-of-Scope list; may be revisited if the DRY wrinkle becomes painful. - Inline config.js baseline (chosen): git-tracked audit trail, flows down as defaults, no external dependency; accepts the two-places DRY wrinkle and a global blast radius for a bad config.js.
Consequences
Section titled “Consequences”- Positive: policy changes are fully auditable via cluster-repo git history; new repos receive the baseline automatically on discovery with no renovate.json required; a bad config.js is bounded to the pod restart/sync cycle and rolled back by reverting one PR.
- Negative: the baseline lives in both config.js and the cluster repo’s own .github/renovate.json and can drift; a config.js parse or semantic error affects all three accounts simultaneously until reverted.
- Neutral: the preset-repo option stays explicitly out of scope and documented as a future escape hatch.