3.6 KiB
ctrl/versions.env
Pinned toolchain
The single manifest ctrl/deps.sh installs from. Every entry is a single binary; none of them needs an apt repo.
- kubectl — fully static
- kind — libc only
- tilt — libc + libstdc++ + libgcc (present in base Debian)
- jq — upstream static build (Debian's is linked against libjq/libonig)
Checksums are the upstream-published SHA256 of the linux/amd64 artifact.
Bumping a pin
Change the version, then take the checksum from the release's own published list — never hand-edit or hand-copy one from a download you did. For anything hosted on GitHub releases that is:
curl -sSL https://github.com/<org>/<repo>/releases/download/<tag>/checksums.txt \
| grep linux.x86_64
(kubectl publishes its own instead: <KUBECTL_URL>.sha256.)
There was a ctrl/versions-refresh.sh named here that has never existed. If bumping stops being rare enough to do by hand, write it — but a comment pointing at a missing script is worse than no comment.
ctlptl
Creates a kind cluster WITH a local registry wired in, which is what keeps images off docker.io (an unqualified name means docker.io/library/<name>). Same publisher and same archive shape as tilt: binary at the archive root, so fetch_tgz handles it with strip=0 and no special case.
docker compose
The distro docker packages ship the daemon and the CLI but frequently not this, so docker compose up fails with "unknown command" on an otherwise working Docker. It is a CLI plugin, found by NAME in a plugin directory, so a copy in the bin dir alone only gives you the retired docker-compose v1 spelling; deps.sh links it into ~/.docker/cli-plugins.
Node images
Node images shipped with KIND_VERSION, pinned by digest so a kind upgrade can never silently move the k8s version. K8S_VERSION selects one (a profile or an overlay's rig.env may set it; the default is the newest pinned). Older entries are kept deliberately, for targets that run an older Kubernetes.
Workload images are not pinned here
What an overlay runs is pinned by the overlay: examples/data/rig.env carries its postgres, redis and airflow images. This file holds what rig itself needs — the toolchain, the node images, the registry and rig's own addons — so it never says what any particular environment runs.
The addons' manifests
metallb, cert-manager and metrics-server are installed from their upstream manifests. Those are pinned here by URL and SHA256 like the binaries, fetched through the same DEPS_SOURCE resolver (upstream, artifactory, baked) by deps.sh manifest <NAME>, verified, and applied from vendor/manifests/ — never a URL applied directly. That is what lets the offline example profile install its addons with no network: the deps-full image carries them.
cert-manager and metrics-server publish their manifests as release assets, and GitHub reports each asset's SHA256 (digest in the release API); those are the pinned sums. metallb does not: its manifest is a file in the repository at the release tag, with no published sum. Its pin was taken from a download whose git blob id matched the one GitHub serves for config/manifests/metallb-native.yaml at that tag, and the blob id is kept beside it (METALLB_MANIFEST_GIT_BLOB) so the next bump is checked the same way:
curl -sSL "https://api.github.com/repos/metallb/metallb/contents/config/manifests/metallb-native.yaml?ref=<tag>" | jq -r .sha
(printf 'blob %d\0' "$(wc -c < metallb-native.yaml)"; cat metallb-native.yaml) | sha1sum
Bumping an addon's version means bumping its manifest sum in the same edit; deps.sh manifest refuses a mismatch.