granja: forzar la recompilacion — rsync -a preserva mtime y cargo no rebuildea

Sincronizar el codigo nuevo al worker y llamar a cargo NO basta: rsync -a
preserva el mtime del hub, asi que el fuente recien llegado puede quedar mas
VIEJO que el binario que el worker compilo hace un rato. cargo dice
«Finished in 0.09s», el worker se queda con el hammer anterior, calcula la
huella vieja y el paso 4 falla sin que se vea por que.

Paso el 2026-08-12 al empujar el lab con los -dev: el worker tenia el lab.rs
correcto Y el rootfs correcto, y aun asi divergia. Se arregla con un `touch`
a los fuentes antes de compilar.

El guardian del paso 4 hizo su trabajo: detecto la divergencia y NO dejo
construir. Sin el, el worker habria molido horas sellando en direcciones que
el hub nunca iria a buscar.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Sergio
2026-08-12 01:05:01 +00:00
co-authored by Claude Opus 5
parent 248cd5b270
commit 262a4aeb61
+7 -1
View File
@@ -51,7 +51,13 @@ $SSH "root@$IP" "set -e
rm -rf alpine.viejo"
log "3/4 recompilando hammer en el worker (el binario debe traer el lab en hash_inputs)"
$SSH "root@$IP" "cd $REMOTE && . \$HOME/.cargo/env 2>/dev/null; cargo build --release --bin hammer 2>&1 | tail -2"
# `touch` ANTES de compilar, y no es paranoia: `rsync -a` PRESERVA EL MTIME DEL HUB, así que un
# fuente recién sincronizado puede quedar más VIEJO que el binario que el worker compiló hace un
# rato ⇒ cargo dice «Finished in 0.09s» y no recompila nada. El worker se queda con el hammer
# anterior, calcula la huella vieja y el paso 4 falla sin que se vea por qué (2026-08-12).
$SSH "root@$IP" "cd $REMOTE && . \$HOME/.cargo/env 2>/dev/null
find crates -name '*.rs' -exec touch {} +
cargo build --release --bin hammer 2>&1 | tail -2"
log "4/4 EVIDENCIA: ¿el worker sella en la misma dirección que el hub?"
h_hub=$("$ROOT/target/release/hammer" --store "$ROOT/store" hash "$TESTIGO" | tail -1)