Fallos de Build

Cuando el builder estático falla, el site no se cae: tu build anterior sigue sirviendo hasta que arregles el problema y reconstruyas. Esta página explica dónde se reportan los fallos de build, qué significan los distintos resultados, y qué intentar.

Dónde mirar

Dos lugares te dicen cómo fue el último build:

Dashboard . panel de estado de build. Muestra el estado actual sin rodeos: build en progreso, la hora del último build, Build Failed (con "Last build exited with an error . site may be out of sync. Check build history below."), o Promotion blocked cuando un build perdió demasiadas páginas (se muestra la razón exacta del propio build).
Build history. Los últimos 100 builds se conservan con su salida completa: cada fila muestra OK, Error, o Blocked, el timestamp, el número de archivos escritos (o el mensaje de fallo), y el log completo de build en una sección expandible.
Una URL de estado tipo /health también responde con la hora del último build y si hay un build corriendo actualmente, para monitores.

Los tres resultados

Error . el builder encontró errores de render (por ejemplo un template roto) y se negó a promover. La salida de staging se descarta y la salida viva anterior queda en su lugar. El mensaje de fallo lista los templates que fallaron, como "page.tt for 'about'" (los primeros cuantos, luego el conteo del resto).
Blocked . el build terminó, pero el builder lo comparó contra el último build bueno y vio una caída demasiado grande (más del 80% de las páginas perdidas) o un pico de enlaces rotos o de problemas de accesibilidad, lo que usualmente significa que el build estaba roto aunque "succeeded". El build anterior sigue sirviendo . contenido obsoleto, nunca contenido roto.
OK . todo promovido; la fila muestra cuántos archivos se escribieron más el log completo.

Primeras cosas que intentar

Full rebuild. Un full rebuild limpio re-renderiza cada página desde cero. Si un build incremental parece haber pasado por alto tus cambios, esto limpia la cache de build y reconstruye desde cero; el botón "Full rebuild" del dashboard hace esto (con confirmación; es más lento que el incremental por defecto). La variable de entorno de emergencia CHINASKI_FORCE_FULL=1 hace lo mismo desde un script de ops.
Promote anyway. Si un build fue bloqueado pero estás seguro de que es correcto, "Promote anyway" en el dashboard lo empuja saltándose el guard para ese único build. Esta es un hatch de escape de un solo uso: no resetea las mediciones contra las que el guard compara, y está pensado para seguir siendo un camino inusual.
Chequea el health endpoint. Es la manera más rápida de ver si un problema de entorno preexistente causó el fallo: directorio de salida escribible, espacio de disco libre, archivo del builder presente, el motor de templates compila, y así.

Lo que usualmente causa un build fallido

Las fuentes más comunes de mensajes de fallo son:

Errores de render de templates . una página o un bloque que fallan al renderizar. El mensaje nombra los tres primeros templates que fallaron.
El entorno de arranque: correr el builder como root (lo cual rechaza), archivo de base de datos faltante, o script de build faltante.
Techo de recursos alcanzado. Un build aborta cuando intenta escribir más del presupuesto de escritura de 2 GiB; cada build también tiene un límite de tiempo de reloj de 30 minutos . después de eso el build se mata y la salida anterior sigue sirviendo.
Firma del manifest. Los builds firman su manifest de archivos, y un build en verde sin un manifest firmado válido se trata como un fallo . la promoción aborta. Los entornos de test pueden optar por el lado con un flag de entorno.

Dónde vive el log una vez corregido

Después de un fallo, las filas expandibles del build history son tu mejor herramienta . la salida completa del build fallido está ahí para copiar y pegar en un ticket de soporte, más los conteos de los templates que fallaron para acotar el problema.

Conteos de razones y sus efectos

Un build llega al paso de promoción solo cuando hay cero errores de render. Cualquier error de render (incluso uno) bloquea la promoción de raíz.
Los errores fatales (de inicio de build) mantienen el site vivo corriendo porque el build anterior no se reemplaza tras un fallo.