facts.env

# =============================================================================
#  facts.env — single source of truth for cross-OS installer FACTS (#435, RFC-CLIENT-0003 D3)
#
#  These values MUST be identical across every OS installer path (ONE documented
#  exception, K3S_CUDA_DIGEST below — read its note before adding a second). The costliest drift
#  class of the 2026-07 sweep was facts diverging between implementations — e.g. the
#  k3d/helm pins bumped in bash (#382) but not PowerShell (#410), which failed a real
#  customer install. This file is the authoritative declaration; the values are STAMPED
#  into each consumer (NOT sourced at runtime — the bootstrap stays a single verified
#  file, RFC-0001 R8):
#    • bash        → scripts/lib/common.sh   (K3D_VERSION / HELM_VERSION / K8S_VERSION defaults)
#    • PowerShell  → scripts/install-k8s.ps1 ($script:K3dVersion / $script:HelmVersion)
#
#  Workflow: change a value HERE, run `scripts/check-facts.sh --write` to stamp it into
#  every consumer, and commit. CI runs `scripts/check-facts.sh --check` and FAILS the PR
#  if any consumer drifted from this spec — so a pin bumped in one OS path but not the
#  other (the #410 incident) can no longer ship.
#
#  Format: KEY=value, one per line; # comments and blank lines ignored. Values are bare
#  (no quotes). "latest" is NOT valid here — a pin must be a concrete release tag so
#  installs stay deterministic and immune to the unauthenticated GitHub releases/latest
#  rate limit (#382/#410).
# =============================================================================

# Pinned tool versions (release tags). K3D_VERSION, HELM_VERSION, and K8S_VERSION (the
# k3s image tag k3d creates the node from) are all enforced in BOTH bash (common.sh) and
# PowerShell (install-k8s.ps1 pins K8S_VERSION too and passes it as `--image rancher/k3s:…`).
K3D_VERSION=v5.9.0
HELM_VERSION=v4.2.3
K8S_VERSION=v1.36.3-k3s1

# CUDA base tag for the custom GPU node image (#616/#835). Enforced across BOTH
# installers ($CUDA_BASE_TAG in install-k8s.ps1 and TB_CUDA_BASE_TAG in common.sh,
# each deriving the pulled image tag) and the build artifacts (docker/k3s-cuda/
# Dockerfile ARG, build.sh, and the build-k3s-cuda workflow input default) — a bump
# here must reach all five or a GPU image pull (Windows or Linux) fails.
CUDA_TAG=12.4.1-base-ubuntu22.04

# Digest of the k3s-cuda GPU node image the LINUX installer pulls (backend#1867). The tag
# derived from K8S_VERSION + CUDA_TAG above is MUTABLE -- a rebuild republishes it --
# so a tag alone lets a re-pushed image onto customer clusters with no review.
#
# HOW THIS IS ENFORCED, and why NOT by pinning the ref. The obvious fix is to make the
# default ref `tag@digest`. Do not: docker resolves such a ref BY DIGEST and never checks
# the tag, while everything downstream (cluster.sh::_check_existing_cluster_k8s_version,
# both GPU-capability checks) reads the TAG. Measured on ghcr.io --
# `k3s-cuda:v9.9.9-k3s1-cuda-does-not-exist@sha256:<an existing digest>` resolves rc 0,
# while that tag alone is "not found". So a pinned ref converts a K8S_VERSION bump with
# no rebuild from an honest 404 (the client#835 CPU fallback) into silently running the
# OLD k3s under a tag claiming the new one -- worse than the problem the pin fixes.
#
# So cluster.sh pulls BY TAG (keeping that 404 honest) and the pre-pull then asserts the
# tag resolved to THIS digest, dropping to CPU with a specific reason if it did not. A
# republished tag therefore cannot run unreviewed bytes, which is what backend#1867
# asked for, without any ref asserting a version its content does not have.
#
# ONE consumer, deliberately -- this fact is the exception to the both-installers rule
# at the top of this file. The Windows default BUILDS the node image locally
# (install-k8s.ps1 Build-GpuNodeImage) and pulls nothing, so there is no ref to pin
# there; a local build has its own digest by construction. Windows' override/mirror
# paths do pull, but those refs are operator-owned -- the same reason only the ghcr.io
# DEFAULT branch of _gpu_node_image is pinned and TRACEBLOC_K3S_CUDA_IMAGE /
# TRACEBLOC_IMAGE_REGISTRY are left alone (a mirror legitimately re-pushes under its
# own digest, and pinning ours would break air-gapped installs).
#
# BUMPING: this digest is bound to the K8S_VERSION and CUDA_TAG above. Change either
# without re-resolving it and the default ref names an image built for the OLD pin --
# a GPU install would then silently run the wrong k3s. `scripts/check-facts.sh
# --check-published` catches exactly that (exit 4) by comparing this pin against the
# live digest of the derived tag. It is out-of-band, not in `--check`, because a pin
# bump legitimately lands on develop before the rebuild is published.
K3S_CUDA_DIGEST=sha256:fbb1a8cfebcdf32320b493fc614161cd1115603067135c27080ac380e4742e9d

# Timeout budgets (seconds). READY_TIMEOUT — how long the installer waits for the client
# workloads to become Ready — is enforced in BOTH bash (summary.sh) and PowerShell
# (install-k8s.ps1 $ReadyTimeout), the two paths that gate the same readiness wait.
# #562: raised 300 -> 600 so a healthy-but-slow/proxied laptop pulling several GB of
# images doesn't false-report CLIENT_STATE=starting / "not connected". A re-run is
# safe; override per-machine with the READY_TIMEOUT env var.
READY_TIMEOUT=600

# METRICS_WAIT_TIMEOUT — how long each installer gives the k3s-bundled metrics-server
# APIService (v1beta1.metrics.k8s.io) to register before letting helm render, so the
# resource-monitor template's render-time `fail` can't abort the whole release on a slow
# host (#553). Enforced in BOTH bash (install-client-helm.sh) and PowerShell
# (install-k8s.ps1 $script:MetricsWaitTimeout). It MUST be one number: both installers
# advertise the same TB_METRICS_WAIT_S override, so a default raised on one OS and not
# the other would make one documented knob mean two different things.
METRICS_WAIT_TIMEOUT=120