3.3 KiB
ctrl/Tiltfile
Purpose and ownership
rig's half of the dev loop, and rig's file: who we are, the context guard, the registry, the overlay's manifests and the namespaces they use. The workload's half — images, resource names and order, port-forwards — is the overlay's own Tiltfile, which this one includes at the end (see overlay.md). With no overlay named that is examples/starter/Tiltfile, so make tilt on a fresh clone comes up with the two examples running and nothing to edit.
Splitting it is what lets rig be replaced as a whole (✖ S1 in STALE.md).
Nothing hardcoded to this directory
Nothing in the Tiltfile is hardcoded to this directory, deliberately. Every other project here writes its slug into the Tiltfile five or six times by hand, so a copy of the project deploys into the original's cluster until someone remembers to edit all of them. A rig is meant to be copied and renamed, and an overlay moved, so it asks instead.
Who we are, and on which ports
One question to rig, answered by ctrl/ports.sh, which resolves it through lib/config.sh — the same path every other rig script takes. That is the point: the cluster name is NOT the bare directory name (it is lowercased and reduced to a DNS label), and the ports honour anything pinned in ctrl/.env. Recomputing either of those here in Starlark is how two copies end up disagreeing about which cluster they are talking to.
The manifests and the overlay arrive as absolute paths, or - when there is none.
Refuse to deploy into the wrong cluster
Tilt snapshots the kubectl context at startup, BEFORE parsing this file, so it cannot be switched from here — only refused. make tilt passes --context for you; the guard catches a bare tilt up after some other project moved the global context.
Images go to this environment's own registry
Fail closed. Tilt can usually infer the kind registry on its own, but "usually" is an inference, and when it misses, an unqualified name like app quietly means docker.io/library/app — a push to the public index instead of the registry two lines away. rig runs that registry; name it.
Namespaces
Every namespace the manifests use has to exist before anything lands in it, and kustomize does not guarantee ordering across resources, so the Tiltfile creates them first (idempotent). The Namespaces the manifests declare are grouped as the infra resource, whatever they are called.
Nothing here assumes a namespace is named after the cluster (✖ S4).
Handing over to the overlay
The facts are published as environment variables (os.putenv) and the overlay's Tiltfile is include()d. An included Tiltfile runs from its own folder: os.getcwd(), local() and every relative path in it resolve from the overlay, so it needs no path back into rig and reads the facts with os.getenv:
RIG_CLUSTER RIG_CONTEXT RIG_HTTP_PORT RIG_HTTPS_PORT RIG_TILT_PORT RIG_REGISTRY RIG_OVERLAY_DIR
Catalogue
The blocks that recur across projects moved with the workload's half: examples/starter/Tiltfile carries them, commented, with the parts that are easy to get wrong explained next to them — building an image, a shared base built once, naming and ordering resources, reloading a gateway on a config change, kustomize flags, and reaching a service directly.