El job runme fallaba en el runner real con "could not execute command:
aborted" justo al iniciar "runme run", algo que no se pudo reproducir
localmente (incluso forzando stdin/stdout no interactivos) — probable
diferencia de cómo act_runner en modo nativo/host expone el proceso
frente a una sesión interactiva. Se agrega CI=true y TERM=dumb al job
(convención estándar que muchas TUIs respetan) y --log/--log-file a
runme-ci para que, si vuelve a fallar, el paso de diagnóstico imprima
el log real en vez de repetir el ciclo de adivinar a ciegas.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
source_sha256 en data/generated/site_state.json incluye la ruta
absoluta del checkout (sourceDigest hashea path+contenido), así que
difiere entre el checkout donde se commiteó y el checkout de un job de
CI en otra ruta, aunque el contenido sea idéntico. El job
validate-and-build ya corría sync antes de validate en el mismo
checkout; el job runme no, y por eso runme-check fallaba con
generated_state_stale. Reproducido localmente clonando a otra ruta
antes de aplicar el fix, y confirmado limpio después.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Retira el código del motor (cmd/, internal/, go.mod, templates/,
examples/, scripts de desarrollo Go) — vive ahora en
https://github.com/fenandosr/clusterlog (release v0.1.0). Este
repositorio conserva únicamente content/, data/, config/ y zola.toml:
los datos reales de esta instancia (MCPS).
Se agrega .clusterlog-version (fija v0.1.0) y scripts/fetch-engine.sh,
que descarga el binario y las plantillas del motor por versión fijada
verificando su checksum contra el release. Makefile y
.gitea/workflows/ci.yml se adaptan para descargar en vez de compilar.
RUNBOOK.md y runbooks/ se recortan a las celdas que sí operan sobre
datos reales de esta instancia (sync-check, validate-local, site-build,
review-mine, verify-head); el ciclo de desarrollo del motor mismo
(build/test/vet) vive en su propio repositorio.
Se preserva toda la historia existente: éste es un commit nuevo, no una
reescritura. Ver docs/adr/0005-motor-instancia.md en el repositorio del
motor para el contexto completo de la separación.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Agrega RUNBOOK.md y runbooks/ (fuera de content/, para no interferir con
la publicación de Zola), con reglas de nombres/etiquetas/aislamiento de
celdas mutantes verificadas por clusterlog validate. Instalación pinneada
a v3.17.4 con checksum verificado (scripts/runme-install.sh), un job de
CI separado (.gitea/workflows/ci.yml) que sólo corre celdas ci-safe, y la
decisión documentada en docs/adr/0004-runme-sidecar.md y docs/RUNME.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
El if: a nivel de step no está corriendo de forma confiable en este
runner (act_runner v0.2.13, modo host): el paso 'Publicar en producción'
nunca se ejecutó en 5 corridas distintas, con o sin condición, con o sin
&&, sin dejar ningún rastro en el log. Se fusiona build + condicional +
rsync en un solo step con el if en bash, que sí es determinista.
Confirmado con dos runs reales: sin importar cuál sea, el último step
de la lista nunca se ejecuta ni deja rastro en el log (ni siquiera como
omitido) en este runner (act_runner v0.2.13, modo host). Se agrega un
paso trivial después de 'Publicar en producción' para que éste deje de
ser el último y sí se ejecute.
El paso de rsync a producción no se ejecutó en el primer run exitoso ni
dejó rastro de 'omitido' en el log, a diferencia del paso condicional de
firmas en PR. Se envuelve la condición en ${{ }} (forma explícita) y se
agrega un paso previo que imprime github.ref/event_name/ref_name reales
en este runner, para confirmar si el valor difiere de lo esperado.
install-action falla en el runner de Gitea Actions en modo host: reporta
runner.os='linux' (minúsculas) y la acción sólo reconoce 'Linux'. Se
reemplaza por una descarga directa del tarball de la release fijada.
.github/workflows/ci.yml nunca corrió: Gitea Actions busca los workflows
en .gitea/workflows/, no en .github/workflows/, y además no había ningún
runner registrado en la instancia (0 workflow_runs históricos).
Se registró un runner en modo host en mcps-hpc-01 (mismo binario
act_runner, sin Docker-in-Docker) y se agregó un paso de publicación al
final del pipeline: en push a main, hace rsync de public/ a
/opt/clusterlog/public/, que sirve un contenedor nginx en mcps-net
detrás de Caddy en clusterlog.mcps-epcm.org.
También corrige base_url en zola.toml, que seguía apuntando al dominio
de ejemplo.
fernandoandClaude Sonnet 5