sergio/takana

1#!/usr/bin/env bash
2# farm-worker-loop.sh — loop AUTÓNOMO del worker. Construye la cola recipes/incoming/ en
3# bucle (PROMOTE=0: sólo sella al store local, NO promueve, NO firma, NO toca gitea), con
4# watchdog de disco integrado. El hub (laptop) le mete recetas nuevas vía farm-sync.sh y le
5# baja el store sellado; este loop sólo muele lo que haya, 24/7, sin esperar a nadie.
6#
7# Idempotente: cada ciclo re-escanea incoming/; lo ya-sellado sale por cache-hit (instantáneo),
8# sólo construye lo nuevo. Cuando la cola está toda construida, duerme IDLE_SLEEP y reintenta.
9#
10# Lo lanza systemd (hammer-farm.service). Manual:  JOBS=2 ./scripts/farm/farm-worker-loop.sh
11set -uo pipefail
12HAMMER_DIR="${HAMMER_DIR:-/opt/hammer}"
13cd "$HAMMER_DIR"
14. "$HOME/.cargo/env" 2>/dev/null || true
15# JOBS=1 MIENTRAS EL ADR 0012 ESTÉ SIN DECIDIR (2026-07-22). `build-farm.sh` usa `xargs -P$JOBS`, y
16# con >1 dos recetas que compartan dep disparan la carrera del árbol de fuentes: ambas hacen fetch
17# del mismo `work/sources/<dep>-<sha>`, una borra mientras la otra usa, y el árbol queda ROTO PARA
18# SIEMPRE. Se vio a escala: al invalidar libdrm, 118 de las 205 recetas KDE tuvieron que reconstruir
19# de verdad (antes eran cache-hits que ocultaban el problema) y ~93 murieron con
20# "/src/.zwrap/cc is not a full path to an existing compiler tool" — el wrapper de zig que la receta
21# deja EN EL ÁRBOL DE FUENTE, barrido por el fetch concurrente de otra receta sobre el mismo qtbase.
22# El reintento serial de build-farm tampoco las salva, porque el árbol ya quedó inconsistente.
23# Serializar es la única mitigación correcta hasta que el ADR 0012 elija (lock por árbol / árbol
24# privado / caché inmutable + copia). Subirlo otra vez sin resolver eso reintroduce el bug.
25JOBS="${JOBS:-1}"
26IDLE_SLEEP="${IDLE_SLEEP:-300}"
27# Fichero de lock compartido con campana-deuda.sh (mismo path en los dos, o no hay exclusión).
28LOCK_FARM="${LOCK_FARM:-$HAMMER_DIR/work/.farm-build.lock}"
29mkdir -p "$HAMMER_DIR/work"
30
31# --- watchdog de disco: cada 3 min borra work/sources/* que ningún bwrap activo bind-monta
32# (seguro: sellada=store CAS, en-cola=se re-extrae sola). Evita que el vendoring llene el disco.
33# Además, si el disco supera DISK_HIGH%, purga los CACHES Go (GOMODCACHE ~/go/pkg/mod + gocache):
34# el `go mod vendor` de las recetas Go acumula ahí decenas de GB sin tope (el vendor/ local de cada
35# receta ya tiene lo que el build necesita; el modcache sólo se usa DURANTE el vendor). Si la purga
36# pisa un vendor en curso, esa receta reintenta el próximo ciclo (cache-hit el resto). Sin esto, una
37# tanda Go grande llena el disco de 80G y el I/O-wait dispara el load (cuello real, no CPU/RAM).
38DISK_HIGH="${DISK_HIGH:-82}"
39(
40  while :; do
41    sleep 180
42    # Protección 1: árboles que un bwrap activo bind-monta (fase compile dentro del sandbox).
43    active=$(pgrep -af bwrap 2>/dev/null | grep -oE 'work/sources/[^ ]+' | sort -u)
44    # Protección 2: árboles cuya receta tiene un `hammer build` EN VUELO. Durante el fetch/`go mod
45    # vendor`/resolve_phases (host-side, ANTES de que arranque el bwrap) el árbol no está bind-montado
46    # ⇒ la protección 1 no lo cubre. Una tanda Go con árbol de deps enorme (dnscontrol/lazysql) tarda
47    # minutos vendoreando; sin esto, el watchdog le borra el go.mod a mitad → "no build system".
48    building=$(pgrep -af 'release/hammer' 2>/dev/null | grep -oE '[^ ]+\.toml' | sed 's#.*/##;s#\.toml$##' | sort -u)
49    for d in work/sources/*/; do
50      [ -d "$d" ] || continue; dd=${d%/}
51      printf '%s\n' "$active" | grep -qxF "$dd" && continue
52      nm=$(basename "$dd"); nm=${nm%-*}   # work/sources/<name>-<sha40> → <name> (el sha no trae '-')
53      printf '%s\n' "$building" | grep -qxF "$nm" && continue
54      # Protección 3: árbol CALIENTE (modificado hace <2 min) ⇒ se está extrayendo AHORA. Una dep
55      # transitiva (p.ej. cairo bajo pango/gtk4) se extrae host-side ANTES del bwrap y con un nombre
56      # que NO coincide con la receta en vuelo ⇒ protecciones 1 y 2 no la cubren. Sin esto, el rm -rf
57      # compite con el tar y deja el árbol a medias ("Cannot mkdir" / luego "Directory not empty" para
58      # siempre). Un árbol en frío (extracción ya fallida/terminada) queda purgable ⇒ se re-extrae limpio.
59      [ -n "$(find "$dd" -mmin -2 -print -quit 2>/dev/null)" ] && continue
60      rm -rf "$dd"
61    done
62    use=$(df --output=pcent "$HAMMER_DIR" 2>/dev/null | tr -dc '0-9')
63    if [ -n "$use" ] && [ "$use" -ge "$DISK_HIGH" ]; then
64      # OJO: `go clean -modcache`/`-cache` borran ~/go/pkg/mod y ~/.cache/go-build ENTEROS. Ambos los
65      # usa `go mod vendor` (modcache p/ módulos, go-build p/ verificar el grafo). Si la purga corre
66      # mientras un vendor está activo —o en la VENTANA justo antes de que arranque (otra receta de la
67      # cola en serie)— le arranca el cache bajo los pies (`.partial`/`go-build/...: no such file`) y
68      # ESE vendor falla. La purga de work/sources de arriba ya liberó lo grueso (segura: saltea las
69      # protegidas). Por eso NO purgo las caches Go si hay CUALQUIER `hammer build` en vuelo (no solo
70      # un `go mod vendor` visible en este instante): difiero al próximo tick / al gap idle entre
71      # ciclos. El sandbox `go install` usa GOCACHE=/src + -mod=vendor ⇒ no toca estas caches del host.
72      if pgrep -f 'go mod vendor' >/dev/null 2>&1 || pgrep -f 'release/hammer.* build ' >/dev/null 2>&1; then
73        echo "$(date -u +%FT%TZ) watchdog: disco ${use}% ≥ ${DISK_HIGH}% pero hay build en vuelo ⇒ difiero purga caches Go"
74      else
75        echo "$(date -u +%FT%TZ) watchdog: disco ${use}% ≥ ${DISK_HIGH}% ⇒ purgo caches Go"
76        go clean -modcache 2>/dev/null; go clean -cache 2>/dev/null
77      fi
78    fi
79  done
80) &
81
82# Colas a construir (sólo SELLA, PROMOTE=0; el hub promueve+firma). `recipes/incoming` es la cola de
83# staging general; `recipes/incoming-go` es la AISLADA del frente Go (pre-sembrada para moler 24/7).
84# build-farm hace `rm -rf work/farm` al inicio ⇒ construirlas EN SERIE (una por vuelta) es seguro,
85# sin colisión. El glob es TOP-LEVEL (`$Q/*.toml`), así que `recipes/incoming/.deferred/` NO se
86# muele — es un subdir a propósito.
87#
88# ⚠ QUÉ HAY REALMENTE AHÍ (revisado el 2026-09-01, y no era lo que decía este comentario). Eran 24 y
89# quedan 19: se retiraron `dprint`, `git`, `gmp`, `mise` y `yj` porque **ya se habían resuelto en
90# otro fichero y sellan** (`recipes/git.toml`, `recipes/mise.toml`, `incoming-kde/gmp.toml`…). Su
91# copia aparcada era la versión ANTERIOR y seguía leyéndose como deuda abierta. El ejemplo que este
92# comentario daba —«git con muro en libgit.a»— era justamente uno de esos cinco.
93#
94# Y no son «aparcadas con diagnóstico»: las 19 que quedan son **volcado CRUDO del importador**, 15
95# de `import-nix` y 4 de `import-alpine`, todas con la misma cabecera «PUNTO DE PARTIDA, no final».
96# Nadie las intentó todavía; no hay ningún muro documentado que respetar. ⇒ Es una cola de trabajo
97# sin empezar, no una lista de imposibles, y conviene no leerla como lo segundo.
98# `incoming-clib` SE RETIRÓ el 2026-09-01: era la cola de staging de las tandas base-system/foot, y
99# sus recetas ya se habían PROMOVIDO a canónicas (`recipes/`) commit a commit —«promover 7 tier-2 a
100# canónicas», «promover cadena crypto», «promover tllist/utf8proc/scdoc/fcft/foot»—. Lo que quedaba
101# eran 0 recetas y 26 PARCHES sueltos. Y eran inalcanzables por construcción, no por descuido:
102# `fetch::apply_patches` resuelve `recipe.base_dir.join(nombre)` y `base_dir` es el directorio de la
103# receta, SIN fallback a `recipes/` ⇒ un parche en una cola sin recetas no lo puede pedir nadie.
104# ⚠ Corolario para cuando se promueva una cola: los `.patch` NO viajan con la receta. Promover deja
105#   la cola en un estado que parece vivo (tiene ficheros) y no muele nada.
106#
107# `incoming-go` NO existe como directorio y se queda en la lista A PROPÓSITO: es la cola aislada del
108# frente Go, y el guard `ls "$Q"/*.toml` salta las colas vacías. Quitarla sería el error que los dos
109# párrafos de abajo documentan, pero al revés: el día que ese frente la recree, nadie la molería.
110#
111# ⚠ EL ORDEN IMPORTA Y LAS COLAS GNOME VAN ANTES DE KDE (2026-08-06). Este default se escribió cuando
112# `incoming-gnome-onda1` era el frente GNOME entero, y quedó fósil: faltaban `incoming-gnome` (86
113# recetas, donde viven gtk4/mutter/gnome-shell) y `incoming-gnome-onda2` (la isla dinámica). O sea que
114# el worker decía moler GNOME y molía 6 recetas de 114. Además iban DESPUÉS de las 205 de KDE, así que
115# aunque hubieran estado listadas, un ciclo con la cola KDE llena las dejaba sin turno.
116#
117# ⚠ EL MISMO FÓSIL, OTRA VEZ (2026-08-29). El párrafo de arriba se escribió por GNOME y la lección no
118# se aplicó a las colas que nacieron después: `incoming-cosmic` (47 recetas) e `incoming-wlr` (15)
119# NUNCA estuvieron acá. El worker decía moler la granja y no tocaba ni una de las 25 recetas en deuda
120# de COSMIC — no fallaban, es que nadie las intentaba. Es el mismo modo de fallo que "el corpus no
121# está en las QUEUES del worker": una cola ausente no da error, da silencio.
122# REGLA: crear una cola `recipes/incoming-*` y no añadirla acá es dejarla muerta. Si aparece una
123# nueva, va en esta línea EN EL MISMO COMMIT. Y la simétrica: si una cola se RETIRA, sale de acá en
124# el mismo commit, o el worker muele un glob vacío para siempre sin que nada lo diga.
125#
126# `incoming-gnome-onda1` SE RETIRÓ el 2026-09-01, y el motivo cierra el arco de los dos párrafos de
127# arriba: sus 6 recetas eran 4 duplicados byte a byte de `incoming-gnome` —mismo ArtifactHash, o sea
128# que sellaban en la MISMA dirección y entraban por cache-hit—, más `gnome-desktop` sin
129# `xkeyboard-config` en `[deps]`, más un `gsettings-desktop-schemas` con `introspection=false`, que
130# es la versión ANTERIOR al 2026-07-28 (mutter necesita el `GDesktopEnums-3.0.gir` que sale de ahí).
131# Al jubilar `gnome-desktop` las dos hojas de la cola se quedaron sin consumidor: molía para nadie.
132# ⚠ Lo caro no era el tiempo —todo salía por caché— sino que el `gsettings-desktop-schemas` viejo
133# competía por el NOMBRE con el bueno: dos artefactos homónimos con hash distinto en el store.
134#
135# `incoming-gnome-onda2` —«la isla dinámica» del párrafo de arriba— se retiró el mismo día, y es el
136# caso LIMPIO del mismo fenómeno: sus 22 recetas eran idénticas a las de `incoming-gnome` y las 22
137# con el MISMO ArtifactHash, o sea la misma dirección del store. Sin divergencias, sin colisión de
138# nombre y sin un solo artefacto que podar al retirarla. El andamio ya no sostenía nada: el trabajo
139# de la isla dinámica vive en `incoming-gnome`, que es la cola que el perfil usa (119/119).
140# ⇒ La comprobación que decide NO es `diff` de las recetas sino `hammer hash`: la resolución de deps
141#   es hermano→padre, así que dos ficheros idénticos en colas distintas PUEDEN sellar distinto.
142# Orden: las colas con deuda van ANTES de las cerradas (kde 163/163, wlr 129/129 salen por cache-hit).
143QUEUES="${QUEUES:-recipes/incoming recipes/incoming-go recipes/incoming-gnome recipes/incoming-cosmic recipes/incoming-kde recipes/incoming-wlr}"
144
145# REBUILD DEL BINARIO AL ARRANCAR (2026-07-18): el hammer horneado en la imagen golden ENVEJECE.
146# Caso real que costó una noche de KDE: la golden del 29-jun traía un hammer sin el fix del overlay
147# lowerdir (commit e69eaaa, 12-jul) ⇒ toda receta de muchas deps (kio=52, kwin, plasma-*) desbordaba
148# el límite de 4KB del mount options y el sandbox NI ARRANCABA — 43 recetas atascadas jurando "en
149# cola". El source SÍ llega fresco (farm-sync rsync-ea el repo), pero nadie recompilaba. Reconstruir
150# aquí garantiza que el worker corre el CÓDIGO VIGENTE, no el fósil de la imagen. Cacheado: ~24s si
151# no cambió nada, minutos en frío. Si cargo falla, seguimos con el binario que haya (mejor que abortar).
152if command -v cargo >/dev/null 2>&1; then
153  echo "$(date -u +%FT%TZ) rebuild hammer desde el source rsync-eado (evita el fósil de la golden)…"
154  cargo build --release --bin hammer -j"$JOBS" 2>&1 | tail -2 || echo "  ⚠ rebuild falló — uso el binario existente"
155fi
156
157echo "$(date -u +%FT%TZ) worker-loop arrancado: JOBS=$JOBS IDLE_SLEEP=$IDLE_SLEEP QUEUES='$QUEUES'"
158while :; do
159  total=0
160  for Q in $QUEUES; do
161    n=$(ls "$Q"/*.toml 2>/dev/null | wc -l)
162    [ "$n" -gt 0 ] || continue
163    total=$((total + n))
164    echo "$(date -u +%FT%TZ) ciclo: $n recetas en $Q"
165    # LOCK COMPARTIDO CON campana-deuda.sh (2026-07-22): ambos construyen sobre el mismo work/, y
166    # `fetch` nombra el árbol de fuentes de forma determinista (`work/sources/<receta>-<sha16>`) ⇒
167    # dos procesos que construyan la misma DEP apuntan al mismo directorio y uno hace `remove_dir_all`
168    # mientras el otro corre `tar -x`, dejándolo a medias con "Directory not empty" (os error 39) para
169    # siempre. Se toma POR COLA y se suelta al terminarla, en vez de por bucle entero. Más fino no
170    # se puede sin romper el `xargs -P2` de build-farm.sh.
171    # OJO con la expectativa: `flock` NO es FIFO. Como el loop vuelve a pedirlo enseguida, suele
172    # ganarle la carrera a la campaña que espera; medido, la campaña entra al terminar TODAS las
173    # colas, no entre dos. La ventana real es el IDLE_SLEEP. Por eso la campaña espera con techo
174    # (LOCK_WAIT) y sale limpia si no entra, en vez de colgarse.
175    # NO cubre el `-P2` interno: dos recetas de la MISMA cola que compartan dep siguen pudiendo
176    # pisarse. Ese es el arreglo de fondo, un lock por árbol dentro de `fetch`.
177    # El `flock -n` primero es sólo para poder DECIR que estamos esperando: si el log dijera
178    # "ciclo: N recetas" y después nada, parecería que el loop trabaja cuando en realidad está
179    # bloqueado, y ese malentendido es exactamente el que cuesta horas de diagnóstico.
180    (
181      if ! flock -n 9; then
182        echo "$(date -u +%FT%TZ) esperando el lock de build (campana-deuda lo tiene)…"
183        flock 9
184        echo "$(date -u +%FT%TZ) lock tomado, sigo con $Q"
185      fi
186      JOBS="$JOBS" PROMOTE=0 QUEUE="$Q" scripts/build-farm.sh 2>&1 | tail -50
187    ) 9>"$LOCK_FARM"
188  done
189  if [ "$total" -gt 0 ]; then
190    echo "$(date -u +%FT%TZ) ciclo terminado; store sellado disponible para el hub"
191  else
192    echo "$(date -u +%FT%TZ) colas vacías; durmiendo ${IDLE_SLEEP}s"
193  fi
194  sleep "$IDLE_SLEEP"
195done