Files
home-network-k3s-impl/infra/devcontainer/versions.env
jakman85andClaude Opus 5.5 60e3a24652
gate / gate (pull_request) Successful in 3m1s
gate / conformance (pull_request) Skipped
images / images (pull_request) Successful in 44s
feat(devcontainer): bake velero CLI into the toolbox, pinned to prod server v1.18.2
The velero CLI and server are version-coupled, so VELERO_VERSION follows the
server running on prod (docker.io/velero/velero:v1.18.2, chart 12.2.3,
verified 2026-11-07). It has no renovate marker on purpose: bump it together
with the chart's appVersion. The verify stage asserts that
`velero version --client-only` reports the pin. The build arg reaches CI
through build-image.sh --print-build-args, so no .gitea/ or ci/ change is
needed.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-11-07 23:18:21 -06:00

63 lines
3.8 KiB
Bash

# Pinned toolchain for the home-network-k3s dev container (the reproducible baseline).
# The non-Python prereqs (OpenTofu, age, sops, flux) are Go binaries, so — per the
# operator's rule — they are baked into a container image instead of a venv. The
# conformance test toolchain (kyverno CLI, kyverno-json, chainsaw, yamllint,
# check-jsonschema, yq, promtool) is likewise baked in so `make -C ci gate` runs here == in CI.
#
# NOTE: these are best-effort pins; bump to current stable if a download 404s at build.
# The conformance-tool versions below MUST stay in lockstep with ci/versions.env.
FEDORA_VERSION=44
OPENTOFU_VERSION=1.9.0
AGE_VERSION=1.2.1
SOPS_VERSION=3.9.4
FLUX_VERSION=2.4.0
# Aligned with ci/versions.env (KUBECTL=1.36.4) and the k3s 1.36.4 cluster.
KUBECTL_VERSION=1.36.4
HELM_VERSION=3.16.0
# --- Conformance test toolchain (match ci/versions.env) ----------------------
KYVERNO_VERSION=1.19.0
# ci/versions.env pins KYVERNO_JSON_VERSION=0.0.5, but NO such release exists:
# kyverno/kyverno-json's highest tag is v0.0.3 (git ls-remote --tags), and the
# platform's own platform/kyverno/scripts/run-l0.sh already defaults to v0.0.3.
# 0.0.5 is an erroneous pin in ci/versions.env — flagged to PM to correct there.
# We bake the real, platform-aligned v0.0.3 so the image builds. kyverno-json is
# NOT invoked by any static gate stage (ci/l0.sh uses `kyverno test` + check-jsonschema).
KYVERNO_JSON_VERSION=0.0.3
CHAINSAW_VERSION=0.2.12
YAMLLINT_VERSION=1.35.1
YQ_VERSION=4.44.6
CHECK_JSONSCHEMA_VERSION=0.29.4
# promtool — the Prometheus rule linter + UNIT-TEST runner (`promtool test rules`), which is
# what evaluates platform/**/*.promtool-test.yaml in the L0 gate
# (conformance/tests/l0-static/alert-rules-unit-tested).
#
# THIS PIN IS NOT FREE-FLOATING: it MUST equal the Prometheus version actually running on prod,
# because promtool is the rule ENGINE and a different major/minor can parse or evaluate PromQL
# differently — a unit test green under one engine and red under the other is worse than no test.
# Verified against the live cluster on 2026-09-12:
# kubectl --context k3s-prod get prometheus -n monitoring -o jsonpath='{.items[*].spec.version}'
# -> v3.14.0-distroless (image quay.io/prometheus/prometheus:v3.14.0-distroless)
# When kube-prometheus-stack ships a new Prometheus to prod, bump this (and ci/versions.env) with
# it; the L0 check asserts the promtool on PATH reports exactly this version, so a drifted
# toolchain FAILS the gate instead of quietly testing with the wrong engine.
# promtool ships INSIDE the prometheus release tarball (prometheus-<v>.linux-<arch>.tar.gz), so
# the version string here is a Prometheus release, not a separate promtool release.
PROMTOOL_VERSION=3.14.0
# velero — the operator CLI for the Velero backup server (platform/velero): `velero backup
# describe <name> --details`, `velero backup logs`, `velero backup create --from-schedule`.
#
# THIS PIN IS NOT FREE-FLOATING: the CLI and server are VERSION-COUPLED (the CLI talks to the
# server's CRDs and its download-request protocol; upstream supports only a matching minor), so
# it MUST equal the Velero server version actually running on prod.
# Verified against the live cluster on 2026-11-07:
# kubectl --context k3s-prod -n velero get deploy velero \
# -o jsonpath='{.spec.template.spec.containers[0].image}'
# -> docker.io/velero/velero:v1.18.2 (HelmRelease velero, chart velero-12.2.3)
# Deliberately carries NO `# renovate:` marker: it must move WITH the server, i.e. when a
# vmware-tanzu `velero` chart bump (platform/velero/helmrelease.yaml, range >=12 <13) changes the
# chart's appVersion, bump this in the same PR. Never bump it on its own. The verify stage
# asserts `velero version --client-only` reports exactly this version.
VELERO_VERSION=1.18.2
# Proxmox provider (bpg/proxmox) is pinned in the tofu module (infra/tofu/versions.tf), not here.