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. 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

# 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