Commit Graph
14 Commits
Author SHA1 Message Date
sergio 4bb5e67e82 Etapa G: harvest-go sale temprano si la cola está vacía (evita rsync del store de GB en balde) 2026-06-29 10:35:19 -04:00
sergio efd670a666 Etapa G: git-town PROMOVIDO (go.work, Git Town 23.0.3) + kustomize flags=./kustomize + gate alias go-mockery→mockery 2026-06-29 10:13:16 -04:00
sergio 237f9796e7 Etapa G: gate alias soft-serve→soft (charmbracelet) + re-encola soft-serve (falso-rechazo) 2026-06-29 09:12:45 -04:00
sergio 254c5a9cc7 Etapa G: ronda 2 pre-siembra finde (+18 Go) + alias gate argo-rollouts/step-cli
terrascan/tfsec/tflint/tparse/richgo/curlie/dockle/vendir/kubefwd/kubeshark/ktunnel/duplicacy/
go-junit-report/argo-rollouts/gowitness/shuffledns/dnscrypt-proxy/step-cli. Dropeados ssh-vault
(sin marca Go) y skopeo (CGO gpgme). Gate: argo-rollouts→kubectl-argo-rollouts, step-cli→step.
2026-06-27 07:04:38 -04:00
sergio b1525ec203 Etapa G: harvest-go fija GIT_SSH_COMMAND (clave github5/tawasuyu) p/ push desde cron sin agente 2026-06-27 07:00:23 -04:00
sergio b544ad3d59 Etapa G: harvest gate exige binario == nombre esperado (no solo que 'corra')
La 1ª corrida promovió+FIRMÓ binarios equivocados que pasaban el smoke por solo 'correr':
katana/naabu→functional-test, gosec→gosecutil, buf→protoc-gen-buf-lint (detect_go_main eligió un
main helper). El gate ahora localiza el binario cuyo nombre == receta (o alias conocido tofu/mc/
nats/dlv/flux/ct/kubeseal/node_exporter/...); si instaló otro → a needs-review-weekend con el motivo,
NO se firma. Lección eksctl aplicada al gate.
2026-06-27 06:50:03 -04:00
sergio c381e1b0c7 Etapa G: modo finde desatendido — worker muele incoming-go/ + harvest-go.sh (cosecha-only gated)
- farm-worker-loop.sh: construye QUEUES='recipes/incoming recipes/incoming-go' (en serie por vuelta;
  la cola Go aislada se muele 24/7 sin pisar el incoming/ del otro agente).
- scripts/farm/harvest-go.sh: cosecha determinista sin IA (cron del laptop). Baja el store sellado,
  y por cada receta SELLADA (cache-hit bajo timeout, NO compila en el hub) hace SMOKE-TEST del binario
  (existe + corre version/--help sin panic/segfault) antes de promover+firmar. Lo que falla el smoke va
  a tandas/needs-review-weekend/ para el lunes. add explícito (nunca -A), push con reintento.
2026-06-27 06:41:28 -04:00
sergio c270edade7 Etapa G: watchdog no purga caches Go con CUALQUIER hammer build en vuelo (no solo vendor)
vault (go-15) falló en 'go mod vendor' con '~/.cache/go-build/...: no such file': durante el compile
de telegraf el disco cruzó DISK_HIGH, el watchdog corrió 'go clean -cache', y el vendor de vault (que
usa esa cache) arrancó en la ventana siguiente sin ficheros. El guard anterior solo miraba 'go mod
vendor' activo en ese instante; ahora difiere la purga si hay cualquier 'hammer build' en vuelo.
2026-06-27 03:30:50 -04:00
sergio ad7ec4aea4 Etapa G: watchdog protege árboles con 'hammer build' en vuelo (fase host vendor/resolve)
go-13 (dnscontrol/lazysql, árboles de deps Go enormes) destapó otra race del watchdog: durante el
fetch/'go mod vendor'/resolve_phases (host-side, antes del bwrap) el árbol no está bind-montado ⇒ el
watchdog lo borraba a mitad del vendor → go.mod desaparecía → 'receta sin compile, heurística no
encontró build system'. Ahora además protege work/sources/<name>-* si <name> tiene un proceso
'hammer build' activo (cubre toda la vida del build, no solo la fase sandbox).
2026-06-27 01:07:09 -04:00
sergio 06ba417336 Etapa G: granja Go pesada — watchdog no purga modcache con vendor activo + syncthing main en cmd/
go-12 (terraform/k8s) destapó la race: con árboles de deps de varios GB en paralelo, el disco
cruza DISK_HIGH y el watchdog corría 'go clean -modcache' a mitad de los 'go mod vendor' en vuelo
(.partial: no such file) ⇒ 5 recetas no convergían. Ahora difiere la purga del modcache si hay un
vendor de host activo (la purga de work/sources ya libera lo grueso y es segura). syncthing: main
real en ./cmd/syncthing (la raíz tiene build-constraints que excluyen todo).
2026-06-26 23:32:12 -04:00
sergioandClaude Opus 4.8 64f4a20072 granja: watchdog purga caches Go cuando disco >=82%
El 'go mod vendor' acumula GOMODCACHE (~/go/pkg/mod) sin tope: una tanda Go
grande lo llevo a 31G y lleno el disco de 80G -> I/O-wait disparo el load a 23
(cuello real, no CPU/RAM). El watchdog ahora purga 'go clean -modcache/-cache'
cuando el disco supera DISK_HIGH% (def 82). El vendor/ local de cada receta ya
tiene lo necesario; si pisa un vendor en curso, esa receta reintenta.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-26 17:36:05 -04:00
sergioandClaude Opus 4.8 b61815a602 Etapa G: worker auto-escala JOBS a nproc (resize del VPS sin tocar config)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-24 06:11:30 -04:00
sergioandClaude Opus 4.8 f9a60ed469 Etapa G: fixes del kit de granja distribuida (validados en VPS Hetzner real)
Tres frentes que aparecieron al provisionar un CCX13 (Ubuntu 24.04) de verdad:
- bootstrap-devfs §3b: el loader musl-256-keys ahora DETECTA la versión del
  rootfs (apk db) en vez de hardcodear 1.2.5. Alpine edge avanzó a musl 1.2.6 ⇒
  un loader 1.2.5 vs coreutils 1.2.6 da `renameat2: symbol not found` → chmod
  roto en el sandbox → el wrapper zig-cc no queda +x → EACCES. case con sha de
  1.2.5 y 1.2.6, die si aparece una nueva.
- vps-setup §2b: compila bubblewrap 0.11.2 si el de la distro no soporta
  --overlay-src (Ubuntu 24.04 trae 0.9.0 sin overlayfs; el sandbox lo necesita).
- farm-sync: excluye /.scratch (44G de fuentes mrustc/rustc) + *.png/content*
  del rsync al worker (casi copia 44G de más).

Smoke test en el VPS: builds compilan código real (pasan cc/chmod), rustc 2
cores al 93%, RAM holgada. Worker funcional.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-24 04:35:57 -04:00
sergioandClaude Opus 4.8 d949d10dcd Etapa G: kit de granja distribuida (worker VPS hub-and-spoke)
Paraleliza el build a un/varios VPS sin exponer gitea ni la clave de firma.
Modelo: el laptop es el HUB (firma + gitea); el worker sólo construye la cola
incoming/ y sella al store local (PROMOTE=0). Reproducibilidad bit-a-bit +
content-addressing ⇒ el store del worker es byte-idéntico, se rsync-ea de vuelta
y el hash valida solo (no hay que confiar en el VPS).

- vps-setup.sh: provisiona Debian/Ubuntu (deps, userns p/bwrap, swap 16G,
  rustup, build hammer, bootstrap-devfs rootfs Alpine edge, systemd unit).
- farm-worker-loop.sh: loop autónomo 24/7, PROMOTE=0, watchdog de disco
  integrado; muele lo que haya sin esperar al hub.
- hammer-farm.service: systemd, JOBS=2 (CCX13 = 2 vCPU dedicado), Nice/idle-io.
- farm-sync.sh (hub): rsync código+cola arriba, store sellado abajo,
  promote+firma+commit+push. Acceso único laptop->VPS por SSH.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-24 03:50:43 -04:00