# kubectl 1.37.0 — el cliente de Kubernetes. Entra por un hallazgo del vigía nuevo
# (`scripts/vigia-subcomandos.py`): el catálogo tenía `kubectl-neat` y `kubectl-tree` SELLADOS y
# **inertes**, porque los dos son subcomandos que despacha `kubectl` y `kubectl` no estaba. Es la
# misma figura que `protoc-gen-go` sin `protoc`: cuatro indicadores en verde —contenido, sonames,
# grafo, reproducibilidad— sobre binarios que no se pueden invocar.
#
# `GOFLAGS=-mod=vendor GOPROXY=off` dentro del sandbox: la fase de compile NO toca la red, usa el
# `vendor/` y punto. `go 1.26.0` pide el `go.mod`; el corpus tiene `go` 1.26.4 ⇒ entra.
# `GOTOOLCHAIN=local` para que Go NO se descargue otro toolchain si algún día el `go.mod` pidiera uno
# más nuevo: eso sería red dentro del sandbox y una entrada fuera del hash.
#
# ⚠ **OJO CON DE DÓNDE SALE ESE `vendor/`, porque NO es el que trae el tarball.** El árbol de k8s
# publica su propio `vendor/` curado, pero el lab corre `go mod vendor` en el FETCH —host-side, antes
# del sandbox— siempre que haya un `go.mod`, sin mirar si el proyecto ya traía uno
# (`takana-build::fetch::vendor_go_deps`, incondicional). Se ve en el log: `go: downloading …`
# ANTES de la fase `configure`. O sea que el `vendor/` que se compila es el REGENERADO.
#
# Acá salió bien —`go.sum` pinea el contenido y la receta REPRODUCE bit a bit, verificado— pero es
# la misma figura que el clobber del `vendor/` de Cargo, que sí tuvo que resolverse con un campo de
# receta (`cargo_vendor_dir`). Queda anotado: si algún día una receta Go depende de un `vendor/`
# PARCHEADO por upstream, el lab se lo va a pisar en silencio.
#
# ⚠ **LOS `-X` NO SON COSMÉTICOS Y UNO DE ELLOS ES UNA TRAMPA DE REPRODUCIBILIDAD.** Sin ellos
# `kubectl version` contesta `v0.0.0-master+$Format:%H$`, que es peor que inútil: un cliente de k8s
# NEGOCIA con el servidor por versión, y varios comandos avisan de desfase cliente/servidor
# comparando estos valores. Los nombres y el formato son los que usa el propio `hack/lib/version.sh`
# de upstream, para no inventar un esquema paralelo.
#
# El de la trampa es `buildDate`: upstream lo llena con `date -u` ⇒ **dos builds del mismo fuente
# darían binarios distintos**, la familia exacta del sello de tiempo de nftables y del `BUILD_ID` de
# valkey. Upstream ya previó el caso y su script respeta `SOURCE_DATE_EPOCH`; acá se hace lo mismo,
# y el lab exporta esa variable con un valor FIJO (`1`), así que la fecha sale constante.
#
# `gitCommit` va pineado a mano porque el tarball de release NO trae `.git` y no hay de dónde
# sacarlo: es el commit al que apunta el tag `v1.37.0` (el tag es ANOTADO, así que hay que resolver
# el objeto tag → commit; quedarse con el sha del tag daría un valor que no es ningún commit).
# `gitTreeState=clean` es verdad: se construye desde un tarball de release intacto.
name    = "kubectl"
version = "1.37.0"
license = "Apache-2.0"

[source]
tarball = "https://github.com/kubernetes/kubernetes/archive/refs/tags/v1.37.0.tar.gz"
sha256  = "956ddae3b12acc08a715aea0411a168a36d5989b3e7185deeb6bf46b7dac19cf"

[build]
compiler = "zig-cc"   # inerte (Go no usa zig); el toolchain real llega por deps.build
target   = "x86_64-linux-musl"
link     = "static"

[deps]
build = ["go"]

[build.phases]
configure = "true"
compile = '''
export GOCACHE=/tmp/gocache GOPATH=/tmp/gopath GOTOOLCHAIN=local CGO_ENABLED=0 GOFLAGS=-mod=vendor GOPROXY=off
V=k8s.io/component-base/version
C=k8s.io/client-go/pkg/version
FECHA=$(date -u -d "@${SOURCE_DATE_EPOCH:-1}" +%Y-%m-%dT%H:%M:%SZ)
COMMIT=f54c212e3a2f75d674b717a9b29052b20b60aefc
go build -trimpath -ldflags "-buildid= -s -w \
  -X $V.gitVersion=v1.37.0 -X $C.gitVersion=v1.37.0 \
  -X $V.gitMajor=1 -X $C.gitMajor=1 \
  -X $V.gitMinor=37 -X $C.gitMinor=37 \
  -X $V.gitCommit=$COMMIT -X $C.gitCommit=$COMMIT \
  -X $V.gitTreeState=clean -X $C.gitTreeState=clean \
  -X $V.buildDate=$FECHA -X $C.buildDate=$FECHA" \
  -o /out/usr/bin/kubectl ./cmd/kubectl
'''
install = "true"