Skip to content

maintenance.md

Latest commit

 

History

History
71 lines (58 loc) · 4.13 KB

maintenance.md

File metadata and controls

71 lines (58 loc) · 4.13 KB
Raw

Maintainability & automated updates

Short answer to "will I get auto-renovate on everything?": yes, on everything that carries a version — with two mechanisms you should know about (the native Terraform manager, and custom regex managers for versions that live outside .tf).

What Renovate keeps current

renovate.json covers:

Thing Where Manager Auto-merge
Terraform providers (upcloud, random, exoscale, hcloud, kubernetes, helm, tls, local, …) every providers/*/versions.tf + modules/* native terraform (globs **/*.tf, recurses all stacks) minor/patch
.terraform.lock.hcl hashes every stack terraform + lockFileMaintenance (weekly) yes
Terraform module sources providers/*/ → ../../modules/* native terraform — (local path, nothing to bump)
RKE2 version (rke2_version default) providers/*/variables.tf customManager → GitHub releases rancher/rke2 minor/patch
Helm chart versions (cert-manager, MetalLB, Longhorn, ECK) modules/rke2-bootstrap/cloudinit/manifests/*.tftpl customManager → helm datasource (reads the repo:/chart:/version: triplet) grouped "kubernetes add-ons"
Container images (haproxy-edge) manifest, flagged with a # renovate: hint customManager → docker minor/patch/digest
GitHub Actions (opentofu/setup-opentofu, actions/checkout) .github/workflows/* native github-actions, digest-pinned yes

Everything is grouped (one "terraform providers" PR, one "kubernetes add-ons" PR, one "github actions" PR) and scheduled Monday pre-6am Europe/Zurich. Minor /patch/digest auto-merge once CI is green; major updates open a labelled PR for manual review. A Dependency Dashboard issue lists everything pending.

What is deliberately NOT auto-updated

  • Node OS image (os_template = "Ubuntu Server 24.04 LTS …"): pinned to an LTS on purpose; bump deliberately (it triggers a rolling node replacement).
  • The add-on charts' app versions inside upstream charts (e.g. the Elasticsearch/Kibana version ECK deploys) — those follow the chart bump.
  • mip-infra itself — it's a separate repo with its own pinned upstream chart commits; this repo only prepares the fork.

Turning it on

  1. Install the Mend Renovate GitHub app on the repo (zero infra), or run the renovatebot/renovate CLI / renovatebot/github-action on a schedule if self-hosting. Same renovate.json either way.
  2. First run opens an onboarding PR + the Dependency Dashboard issue.
  3. CI (validate.yml) runs tofu fmt -check and tofu validate per stack on every PR, so an auto-merged bump that breaks a stack is blocked.

Notes / caveats

  • Providers resolve from the default registry (registry.terraform.io); all providers used here (upcloud, random, exoscale, hcloud, kubernetes, helm, tls, local) are mirrored there, so no OpenTofu-registry override is needed. If you ever pin a provider that is OpenTofu-registry-only, add a registryUrls rule for matchDatasources: ["terraform-provider"].
  • Renovate updates lock hashes for providers already present in a stack's lock file; it won't add a brand-new provider to the lock. When you add a new provider block, run tofu init once locally and commit the lock so Renovate can maintain it afterward.
  • The RKE2 version uses a custom regex: versioning (v<major>.<minor>.<patch>+rke2r<build>) so Renovate orders the +rke2rN suffix correctly.
  • Untested stubs (Exoscale/Hetzner) are validated by CI but their providers won't have lock files until first tofu init — commit those when you bring a stub online.

Why the repo is maintainable beyond Renovate

  • One shared modules/rke2-bootstrap → chart/RKE2 versions live in one place, not duplicated per provider.
  • Each providers/<name>/ is an independent root module with its own state — a change to one provider can't break another.
  • The interface-contract outputs are identical across stacks, so shared tooling (scripts/prepare-mip-infra-fork.sh) never needs per-provider code.