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
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.
47 lines
2.9 KiB
Markdown
47 lines
2.9 KiB
Markdown
# 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.
|