Niklas Ye
ba253b7bf7
- .gitea/workflows/ci.yaml: fmt/lint/test, same no-actions/checkout-and-manual-clone
shape as terdut-server's ci.yaml, and the same reasoning for why (Node/ES2022
incompatibility on the runner image). No chart/security jobs yet -- nothing for
either to check until Stage 6 / real controller code exists.
- CLAUDE.md: Checks + Release sections, matching the sibling repos' convention from
the workspace-level CLAUDE.md ("each repo has its own CLAUDE.md... read it before
working in that repo"). Release is explicitly marked not-wired-yet rather than
copying terdut-server's, since there's no chart to release against until Stage 6.
- ROADMAP.md: moved the .release.conf bullet out of Stage 0 (it names a HELM_CHART
this repo doesn't have yet) -- it was already duplicated into Stage 6, which is
where it actually belongs.
Stage 0 done: `make fmt lint test` verified green locally. Real open question the CI
workflow's comments flag rather than assume past: whether storage.googleapis.com
(envtest's binary source) is reachable from this Gitea runner's container network the
way proxy.golang.org is -- terdut-server's own ci.yaml notes get.helm.sh/github.com are
not. Only running the workflow for real will confirm; the comment names the fallback
(move the job out of `container:`, like terdut-server's chart job) if it isn't.
Terdut operator
Aims to expose most config as CRD's, so end users can self-service over gitops.
See DESIGN.md for the full design: CRD catalog and specs,
reconciliation semantics, bootstrap/auth, Postgres integration, RBAC, and the
relationship to charts/terdut-server. This README stays a short pitch; the
open questions it used to carry are now resolved decisions there (§2).
CRD's
terdutServers
Creates a server — Deployment, Service, database wiring, bootstrap, operator
credentials, and allowedTeams consent for cross-namespace teams. See
DESIGN.md §4.1, §4.6.
terdutTeams
- team name
- oidc groups
serverRef— explicit reference to itsTerdutServer, may be in a different namespace (one team owns the server, others self-service a team against it), gated by thatTerdutServer's ownallowedTeamsfield (DESIGN.md §2, §4.1, §4.2, §4.6)
terdutEscalationrules
- rule
teamRef— explicit reference to itsTerdutTeam(DESIGN.md §2, §4.3)
terdutDeadmansswitches
- rule
teamRef(DESIGN.md §4.4)
terdutAlertSources
teamRef(DESIGN.md §4.5)- URL/key are generated by the server at creation and surfaced only via a generated Secret, never set explicitly