[RFD]: Adopt Renovate for cross-cutting config management

[alexlovelltroy]

Decision Goal

Should OpenCHAMI adopt Renovate (Mend Renovate App free tier) as the org-wide tool for cross-cutting dependency/config version updates, with a shared preset hosted in openchami/.github at renovate-config/default.json, rolled out across the active repo set with a per-repo renovate.json that extends the central preset?

Category

Tooling

Stakeholders / Affected Areas

All maintainers (will see Renovate PRs in their inboxes); the TSC (owns the preset policy); contributors with merge rights (review the PRs); release engineers (action and tool versions affect releases). Mechanical impact lands in openchami/.github (the preset) plus each active repo (a small renovate.json).

Decision Needed By

No hard deadline. Reasonable to aim for completion before the next major OpenCHAMI release cycle so the release pipeline benefits from current action/toolchain versions.

Problem Statement

Maintaining versions across the org's repos is currently manual and drifts predictably. The May 2026 audit and follow-on placement research found:

• Dependabot coverage: 0% across audited repos. No automatic dependency update PRs.
• Renovate coverage: 1 repo (openchami/integration-sandbox/.github/renovate.json). A precedent exists; it just hasn't been generalized.
• Action version drift visible in workflows: actions/checkout pinned at v4, v5, and v6 across different repos audited. Same pattern probably applies to other common actions.
• Go toolchain bumps, pre-commit hook revs, goreleaser config, golangci-lint config: all currently maintained by hand per-repo. Each repo drifts independently.

Renovate solves this with three properties Dependabot doesn't have:

1. Manager breadth. Renovate has native managers for github-actions, gomod, gomod-toolchain (the Go version directive itself), pre-commit, goreleaser, golangci-lint, dockerfile, helm, plus a regex manager for anything custom. Dependabot covers only github-actions, gomod, and docker natively.
2. Shared preset via extends. Each repo's renovate.json can say "extends": ["github>openchami/.github//renovate-config"]. Policy changes happen in one place; every consumer inherits. Dependabot has no equivalent.
3. Grouping and scheduling. Renovate supports grouping (e.g., one PR per week for all minor/patch GHA bumps, one PR per major bump), scheduling (off-hours, business-days only), and stability windows (don't propose v3.7.0 until it's been out 3 days). Manages PR-noise at scale.

This is the cross-cutting "define once, applies everywhere" problem that's hard with Dependabot but Renovate's main use case.

Proposed Solution

Adopt Renovate. Concrete steps:

1. Add the shared preset to openchami/.github at path renovate-config/default.json. Initial preset covers:
   • github-actions — group all GHA bumps; weekly schedule; auto-merge for trusted upstream actions.
   • gomod + gomod-toolchain — group minor/patch; separate PR for majors; respect replace directives.
   • pre-commit — bump hook revs.
   • goreleaser and golangci-lint — bump binary versions referenced in CI.
   • dockerfile — base image bumps.
   • Stability: 3-day delay on non-security updates; immediate for security-tagged.
2. Lift the existing integration-sandbox/.github/renovate.json as the starting point — it has working choices to adapt.
3. Install the Mend Renovate GitHub App on the org for the active set of repos. Mend's free tier covers OpenCHAMI comfortably (≤10 active devs on public repos).
4. Roll out per-repo renovate.json with {"extends": ["github>openchami/.github//renovate-config"]} to the 16 currently-tracked repos (Wave 1), then the rest of the active set (Wave 2).
5. Pair with Dependabot alerts, not Dependabot active updates. (Companion: #131 — org governance baseline RFD, which proposes turning on Dependabot alerts as the org default.) Dependabot watches for CVEs and surfaces them in the Security tab; Renovate opens the routine version-bump PRs. They don't fight.

Alternatives Considered

• Dependabot for everything (no Renovate). Loses the pre-commit, goreleaser, golangci-lint, and Go-toolchain managers — i.e., loses the main reasons to have a cross-cutting tool. Also loses the extends preset model. Workable for the basics but doesn't solve the actual problem.
• A new openchami/renovate-config repo dedicated to the preset. This was the original plan from the vault decision (2026-05-28). Rejected on user feedback: the org already has four "machinery" repos (.github, github-actions, release, community); a fifth dedicated to one config file is sprawl-inducing.
• Host the preset in openchami/github-actions. Rejected because Renovate presets are configuration data, while github-actions is the org's reusable-behavior repo (composite actions + reusable workflows). Mixing data and behavior blurs that repo's purpose. openchami/.github is the org-wide-config repo by convention and already hosts .pre-commit-config.yaml, .yamllint, and workflow templates — same category.
• Status quo (manual). Real cost: action-version drift, missed minor/patch upgrades on toolchains, pre-commit hook staleness accumulating slowly. Manual review can't keep up across 30+ active repos.

Other Considerations

• PR-channel noise. Renovate's default cadence is chatty; the proposed preset uses grouping + scheduling + stability windows to bring it to a few PRs per repo per week. Tunable later.
• Mend free-tier dependency. If the free tier policy changes, the alternative is self-hosting Renovate via GitHub Actions (the project supports it). Not blocking adoption, but worth noting as a known supply-chain-of-the-tool consideration.
• Doesn't solve shared content of config bodies (e.g., identical .golangci.yml across repos). Renovate manages versions, not config content. For shared content, a separate pattern is needed: a reusable workflow in openchami/github-actions that fetches the canonical config at lint-time. Out of scope for this RFD.
• Composes with #130 (recommended docker base images). Renovate's dockerfile manager can keep base-image versions current across repos once the recommended list is agreed. Renovate is the maintenance mechanism that makes the [RFD]: Create a recommended list of base docker images #130 recommendation durable rather than a snapshot in time.
• renovate.json per repo is small (one line). The cost in repo-level files is minimal — just enough to opt in.
• Auto-merge concerns. The initial preset is not aggressive on auto-merge — only trusted upstream GHA bumps auto-merge. Major Go module bumps and core deps always need human review.

Related Docs / PRs

• #131 — Establish baseline org-wide governance (CODEOWNERS, SECURITY, Dependabot alerts, org settings) — companion RFD. Covers the Dependabot alerts side (security CVE surfacing). This RFD covers the active-updates side (version bump PRs). The two are designed to land in the same meeting and partner cleanly.
• #130 — Create a recommended list of base docker images — adjacent. Renovate's dockerfile manager keeps the agreed-on bases current across repos automatically; without an active-updates tool, [RFD]: Create a recommended list of base docker images #130's list becomes a static snapshot that drifts.
• Renovate docs — particularly Shareable Config Presets and the github>owner/repo//path extends syntax.
• Mend Renovate App — the GitHub App; free for public repos.
• openchami/integration-sandbox/.github/renovate.json — the existing in-org Renovate config; useful starting point for the preset.

---

Outcome (to be filled in after discussion)

• Accepted
• Accepted with modifications
• Rejected
• Needs follow-up RFC
• Deferred
• Other: ________

Decision date:
Recorded by:

[rainest]

My prior experience with Renovate as a dependency update manager was fine. If we're not getting what we want from Dependabot, I'm fine with it.

[milliams]

Renovate seems like a good tool and decouples from GitHub specifically. I think we should consider enabling dependency cool-downs as a matter of policy to help mitigate against zero-day supply chain attacks.

[alexlovelltroy]

Great Idea. We can add that to the implementation plan

[alexlovelltroy]

Agreed at the TSC meeting. I'll take action on this and we'll review in a month

[alexlovelltroy]

Based on further discussions, we have decided to retain the github-actions repository because that's what most other orgs do. Trying to limit surprises.