4.0 KiB
ctrl/Tiltfile
Purpose and ownership
This file ships with rig and works unedited: rig's own k8s/base already boots, so make tilt comes up with a running cluster and no editing at all. What it deploys is two EXAMPLES — replace them, and add your own images and resources in the two marked sections near the bottom. The catalogue after them has the blocks to paste, with the parts that are easy to get wrong already commented.
rig supplies this file; it does not own it. Nothing in rig reads it back, and nothing here is regenerated — edit it freely, the way you would edit k8s/base/example-mock.yaml. rig owns the machine, you own the workload.
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, 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.
Where the manifests live
rig's own manifests are the default; point MANIFESTS_DIR in ctrl/.env at an overlay versioned somewhere else and rig stops owning them — see k8s/README.md. Real manifests usually change on a different cadence, by different people, under different review.
The value is REPO-ROOT relative, because that is the root everything else in rig is expressed against. The Tiltfile runs in ctrl/, so prefix rather than assume: '../' + 'ctrl/k8s/overlays/dev' and '../' + '../platform/overlays/dev' are both right, where stripping a leading ctrl/ would only fix the first.
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.
Catalogue
The catalogue holds the shapes that recur across every project here, with the reasoning kept next to them. They are comments so the file runs as-is.
Catalogue: build an image
The one genuinely non-obvious thing in the whole corpus: context and dockerfile are relative to DIFFERENT directories, in adjacent arguments, and nothing warns you.
context=the REPO ROOT — the Tiltfile is in ctrl/, so'..'dockerfile=relative to THIS file — so'Dockerfile.api'is ctrl/Dockerfile.api
Every COPY inside those Dockerfiles is therefore repo-root relative: a file sitting BESIDE the Dockerfile is still reached as COPY ctrl/nginx.conf.
Catalogue: reload the gateway when its config changes
A Caddyfile arriving via configMapGenerator with disableNameSuffixHash does NOT roll the pod — the ConfigMap name never changes, so nothing tells the Deployment anything happened. Without the gateway-reload local_resource you edit the routes and watch nothing take effect.
Catalogue: reach a service directly, bypassing the gateway
For a DB client or an admin UI. Prefer routing through the gateway: host ports are a single shared namespace across every project on this machine, which is why rig derives a block per environment in the first place. If you do need one, take it from this environment's own block rather than picking a number.