Bugs que hacían fallar los deploys de casi todos los proyectos. Contexto + explicación simple.
OpenHarness es nuestra herramienta de CI/CD: cuando alguien hace git push, ella construye la app y la deploya sola a Railway (staging o producción). Cada proyecto tiene un "pipeline" = una cadena de pasos: buildear la imagen → deployar.
El problema: esos pipelines venían fallando. Los deploys no llegaban a producción/QA, o quedaban en rojo al azar. Encontré 3 causas de raíz — ninguna era del código de las apps, todas eran de configuración del pipeline.
{{shortSha}} (doble llave, estilo GitHub Actions), pero OpenHarness usa llave simple {shortSha}. El nombre quedaba literal con las llaves y Docker lo rechazaba.[calle del cliente] en vez de la calle real. El correo lo rechaza.Invalid RAILWAY_TOKEN.RAILWAY_TOKEN="", en vez de usar el token real (que ya estaba como secreto). Sin credencial, Railway rechazaba el deploy.socket hang up).Verifiqué con un scan que ningún pipeline queda con estos bugs:
Todo se hizo solo en la config de los pipelines (vía la API de OpenHarness) — sin tocar el código de ninguna app, sin riesgo de regresión. Los 3 son "falla-segura": si algo salía mal, el pipeline fallaba, nunca deployaba algo roto.
Los fixes de la otra pestaña arreglan la configuración de cada pipeline (uno por uno). Pero encontré 3 debilidades en el motor de OpenHarness (su código) que causaban o agravaban esas fallas. Arreglarlas hace que estos problemas no puedan volver en ningún proyecto — es la red de seguridad de fondo.
The container name is already in use.Failed to fetch Figtree from Google Fonts).docker build una sola vez, sin reintento. Si justo había un hipo de red al bajar la imagen base, paquetes de npm, o las fuentes que Next descarga en el build, el build entero se caía — aunque un simple reintento habría andado.{shortSha}. Si alguien escribía llaves dobles {{shortSha}} (costumbre de GitHub Actions), quedaba literal y rompía el build en silencio.13/08) y si la escribís con guiones (13-08) explota sin avisar. Mejor que la acepte de las dos formas.Los 3 cambios son conservadores y acotados: el reintento solo aplica a errores de red; la pre-limpieza es idempotente; la tolerancia de llaves solo toca variables conocidas. Type-check limpio.