Files
terdut-operator/CLAUDE.md
T
Niklas Ye b4ccdb09d5
Release / test (push) Successful in 2m48s
CI / chart (push) Successful in 1s
CI / security (push) Successful in 1m3s
CI / test (push) Successful in 2m5s
Release / chart (push) Successful in 4s
Release / image (push) Successful in 7m6s
Release / scan-image (push) Failing after 33s
Stage 5: installer chart + release infra, kind e2e pass through the chart
Chart (charts/terdut-operator) generated via kubebuilder's own helm/v2-alpha
plugin from config/'s kustomize output -- CRDs + manager Deployment/RBAC
come from the same markers every other stage already generates, one source
of truth. Hand-added on top: the optional terdutServer values block
(DESIGN.md §10's "helm install and get a server" path, off by default) and
the release-skill plumbing -- .release.conf, release-vars/helm-lint/push/
helm-package/helm-push/release Makefile targets, .gitea/workflows/release.yaml
(test -> image/chart -> scan-image) -- mirroring terdut-server's own shape
(registry/namespace convention, multi-arch buildx push, trivy/govulncheck/
gitleaks scans). ci.yaml gains security and chart jobs to match.

Two real issues caught while wiring this, fixed before either shipped:
- Dockerfile's builder stage didn't pin --platform=$BUILDPLATFORM, which
  would have made a multi-arch release build fail outright on this org's
  runners (no binfmt registration) -- same fix terdut-server's own
  Dockerfile already needed for the same reason.
- govulncheck found one real, reachable finding: google.golang.org/grpc
  v1.82.1 (transitive via controller-runtime's otel exporter), fixed by
  bumping to v1.83.1.

Full golden-path kind e2e pass, this time through `helm install` rather than
raw kustomize: TerdutServer (real terdut-server v0.33.0 image) -> TerdutTeam
-> one of each child kind, each confirmed Ready and then independently
confirmed against terdut-server's own API from inside the cluster (not just
the operator's own status). Deleted every CR in reverse order and confirmed
server-side cleanup the same independent way for all three child kinds, the
team, and the server. No new bugs found -- Stage 1's own kind pass already
caught what a real cluster catches that envtest can't.

Also dropped the kubebuilder helm plugin's default .github/workflows/
scaffold, same as Stage 0 already did for the main scaffold: this org runs
on Gitea, not GitHub.

Not done here, deliberately: an actual tagged release. release-preflight
found no terdut-operator/ entry under Ryuvia/charts yet to bump -- that
one-time wrapper bootstrap is a decision about deploying this operator for
real, not a side effect of finishing this stage.

make fmt lint test helm-lint build all clean.
2026-10-01 14:47:10 +02:00

2.9 KiB

terdut-operator

Kubebuilder/controller-runtime operator for terdut-server. See DESIGN.md for the settled design (CRD catalog, reconciliation semantics, bootstrap/auth, RBAC) and ROADMAP.md for the staged build plan this repo is following. README.md stays the short pitch.

Checks

make fmt lint test helm-lint is the CI gate (.gitea/workflows/ci.yaml's test, security and chart jobs call these targets rather than restating them, same convention as terdut-server). test chains through the Kubebuilder-scaffolded manifests/generate (controller-gen) and setup-envtest targets automatically — everything needed lands in bin/ (gitignored) on first run, no separate tool install required beyond Go itself and network access to proxy.golang.org/storage.googleapis.com. security runs make security-go/security-secrets (govulncheck/gitleaks), same as terdut-server's own security job.

The kubebuilder-scaffolded make test-e2e (a disposable, generic smoke test) is separate from the real golden-path kind e2e pass ROADMAP.md's Stage 5 describes (create every CRD kind, verify against terdut-server's own API, delete, verify gone) — the latter is a manual pass run and recorded in ROADMAP.md, not a CI job, matching Stage 1-4's own precedent of validating against a real cluster outside CI.

Release

Wired as of Stage 5 (ROADMAP.md): .release.conf, make release-vars/helm-lint/ push/helm-package/helm-push/release, and .gitea/workflows/release.yaml (test → image/chart → scan-image) all follow terdut-server's established shape — see that repo's Makefile/.release.conf for the shared reasoning, not restated here.

The chart is charts/terdut-operator (via kubebuilder's own helm/v2-alpha plugin, regenerate with kubebuilder edit --plugins helm.kubebuilder.io/v2-alpha --output-dir charts --force after config/ changes, then re-review — --force does not touch Chart.yaml but does touch values.yaml, which carries hand-written additions, most importantly the optional terdutServer block, DESIGN.md §10). It installs the operator + CRDs + RBAC, and optionally one TerdutServer CR (terdutServer.enabled, off by default).

One manual step the release skill's own automation does not cover: release-preflight expects an existing terdut-operator/ entry under Ryuvia/charts to bump on release (steps 8-10 of the skill). There is no such entry yet — this repo's first-ever release can publish its own image and chart (the test/image/chart/scan-image jobs), but the wrapper-chart bump and PR will fail until someone creates that initial wrapper entry in Ryuvia/charts by hand, the same one-time step every other onboarded repo already had done for it before its own first release. That's a deliberate decision to deploy this operator for real, not something to do as a side effect of finishing this stage.