felhom.eu/.claude/rules/manifests.md

paths

paths
manifests/** **/*.yaml

Manifests — ArgoCD, deliberate sync, secrets

One app, and auto-sync is OFF

The whole cluster is GitOps via a single ArgoCD app felhom syncing this repo's manifests/ to the felhom-system namespace. Auto-sync is OFF — a deploy is a deliberate manual sync.

ArgoCD's source of truth is the manifest in git:

• Committing a manifest change deploys nothing until the app is synced.
• Pin explicit image versions, never :latest.
• Never bare kubectl set image / kubectl apply — the next sync reverts it, so the fix looks like it worked and then silently disappears.
• Sync method (hard-refresh + sync, local sudo kubectl): the felhom-build-deploy skill.

Secrets

• Out-of-band secretKeyRef only — never inline stringData (REUSE.md §3).
• manifest_bearer_gate.py fails on any bearer-shaped literal anywhere under manifests/. It runs from python3 scripts/repo_gates.py.

The two git-syncs in webpage.yaml

manifests/webpage.yaml runs two git-syncs and they track different refs: the website from main, and /scripts/ from the tag installer-v<SCRIPT_VERSION>. Changing either --ref changes what real machines download — the init container and the sidecar both carry it, and both must move together. hostinstall_gates.py gate 6 fails if the manifest stops naming an installer-v… tag or if the website stops tracking main. All four git-sync containers (two sidecars, two init containers) read Gitea in-cluster (http://gitea.gitea-system.svc.cluster.local:3000/…, since 2026-10-19) and must name the same repo — gate 6 fails if they differ; the sidecars carry --max-failures=-1 (retry, never exit). The full publish/rollback procedure is the R-110 fence in the repo core CLAUDE.md.