DevOps

Qué contexto necesita la IA para investigar un pipeline CI/CD fallido

Un log aislado permite localizar dónde terminó una ejecución, pero rara vez explica por sí solo qué cambió para que el pipeline empezara a fallar. Antes de consultar a la IA, conviene reconstruir qué ocurrió entre la última ejecución correcta y la primera fallida. Esa comparación reduce mucho más el espacio de causas que entregar únicamente las últimas líneas del error.

Imaginemos un pipeline que llevaba varias ejecuciones correctas y empieza a fallar en integration-tests después de un merge. El log indica que la aplicación no consigue conectarse a PostgreSQL. El mensaje acota el problema, pero todavía es compatible con varias causas: un cambio en variables, una nueva imagen del runner, una modificación en la definición del servicio, una dependencia diferente o un problema de sincronización durante el arranque. El error observado es una señal; el cambio entre ambas ejecuciones ayuda a localizar dónde investigar.

Reúne la última ejecución correcta y la primera fallida

Prepara para la IA un contexto que permita comparar ambas ejecuciones. Incluye el stage, job y step afectados, las líneas relevantes del log, el exit code cuando exista y los commits, cambios de configuración o actualizaciones de dependencias introducidos entre una ejecución y otra.

Añade solo cuando sean relevantes datos como la imagen utilizada por el runner, servicios auxiliares, versiones, variables de entorno, cachés o artefactos. Si necesitas compartir configuración o valores de ejecución, elimina antes secretos, tokens, credenciales y cualquier dato sensible.

En nuestro caso, saber que el último pipeline correcto utilizaba la misma aplicación pero una configuración anterior del entorno de pruebas hace que ese cambio merezca atención prioritaria. Si además cambió la imagen del runner o la versión de PostgreSQL, esas diferencias deben entrar en la investigación antes de atribuir el fallo a la aplicación.

Cuando el pipeline no conserva suficiente información para realizar estas comparaciones, mejorar su observabilidad puede ser más útil que pedir al modelo que compense con hipótesis la falta de datos.

Separa lo que cambió, lo que observas y lo que todavía supones

Una entrada útil para la IA distingue tres capas. Cambio conocido: se modificó la configuración del entorno. Evidencia observada: integration-tests termina con connection refused al intentar acceder a PostgreSQL. Hipótesis: la variable efectiva es incorrecta, el servicio no está disponible en ese momento o alguna condición del runner ha cambiado.

Esta separación evita convertir una coincidencia temporal en una causa demostrada. La primera petición al modelo debería pedir qué hipótesis son compatibles con los cambios y evidencias disponibles, qué datos faltan y qué comprobación permitiría distinguir unas causas de otras. El objetivo todavía no es arreglar el pipeline, sino decidir dónde mirar primero.

Cómo priorizar causas probables con ChatGPT, Claude o Gemini

Una vez comparadas la última ejecución correcta y la primera fallida, la IA puede ayudar a ordenar causas según su relación con los cambios reales del pipeline. No todas las hipótesis compatibles con un connection refused merecen la misma atención: una modificación reciente en variables, servicios, imagen del runner o dependencias tiene más peso que una posibilidad genérica sin relación con lo ocurrido entre ambas ejecuciones.

En nuestro caso, el fallo aparece en integration-tests tras modificar la configuración del entorno. La investigación debería partir de esas diferencias y del punto exacto donde se rompe el pipeline, no de una lista amplia de causas posibles de PostgreSQL.

Pide hipótesis vinculadas a cambios concretos del pipeline

Entrega al modelo el conjunto de diferencias relevantes entre la ejecución verde y la roja y pídele que relacione cada hipótesis con una de ellas. Por ejemplo: cambio en una variable utilizada por el job, nueva versión de una imagen, modificación del servicio PostgreSQL, dependencia actualizada o alteración del orden entre steps.

Para cada causa candidata conviene obtener tres datos: qué evidencia del pipeline la hace plausible, qué comprobación permitiría evaluarla y qué resultado permitiría descartarla. Si una hipótesis no puede conectarse con ningún cambio ni con una señal observable, debería quedar por debajo de otras mejor respaldadas.

La documentación de depuración de CI/CD de GitLab recomienda revisar precisamente variables, versiones de dependencias, configuración y otros datos de ejecución para aislar el origen de un fallo. Aunque la plataforma cambie, el principio es el mismo: comprobar primero aquello que realmente puede haber variado.

Prioriza por poder de descarte, no solo por probabilidad

La primera comprobación debería ser la que más reduzca la incertidumbre con menor coste y riesgo. Una prueba con alto poder de descarte puede ser más útil que comprobar primero la hipótesis aparentemente más probable.

Si la configuración del host cambió entre ambas ejecuciones, verificar el valor efectivo dentro del job puede descartar rápidamente una rama completa del diagnóstico. Si permanece correcto, tiene sentido pasar al estado del servicio, a la resolución de red o a diferencias en runner e imagen utilizada.

Puedes pedir a la IA que ordene las siguientes comprobaciones según cuatro criterios: relación con cambios recientes, evidencia disponible, capacidad para descartar causas y coste de la prueba. Así, la salida deja de ser una lista de explicaciones y se convierte en un orden de investigación específico para ese pipeline.

Cómo validar una hipótesis sin cambiar cosas al azar

Una hipótesis priorizada solo sirve si puede contrastarse contra el comportamiento real del pipeline. En CI/CD, validar no significa modificar YAML, aumentar timeouts o reiniciar jobs hasta que uno pase. Significa obtener una señal que permita relacionar el fallo con una condición concreta de la ejecución.

En nuestro caso, el valor del host resulta correcto. Esa comprobación reduce el peso de la hipótesis de configuración y desplaza la investigación hacia el estado de PostgreSQL durante integration-tests. A partir de ahí conviene comparar qué ocurre dentro del job: cuándo arranca el servicio, cuándo empieza la prueba y si las condiciones son iguales a las de la última ejecución correcta.

Actualiza el diagnóstico con resultados del propio pipeline

Después de cada comprobación, devuelve al modelo qué se verificó, qué resultado apareció y qué diferencias siguen existiendo respecto a la ejecución correcta. Si PostgreSQL se inicia pero todavía no acepta conexiones cuando empiezan los tests, la hipótesis de sincronización gana fuerza porque ya está vinculada a una condición observable del pipeline.

No repitas una ejecución solo para ver si «esta vez funciona». Una nueva ejecución es útil cuando cambia o mide algo deliberadamente: añade una comprobación de readiness, registra el momento de arranque, muestra el valor efectivo de una variable no sensible o permite comparar runner, imagen, dependencia o artefacto utilizado.

Si el fallo termina dentro de la aplicación y aparece una excepción relevante, puede ser útil complementar el análisis con un método específico para pasar de un stack trace a un diagnóstico con ChatGPT, Claude o Gemini. En ese punto el stack trace aporta evidencia adicional, pero sigue formando parte de una investigación más amplia del pipeline.

Usa una matriz para registrar qué cambió y qué queda por comprobar

Una matriz sencilla ayuda a conservar el estado del diagnóstico y evita repetir pruebas que ya aportaron una conclusión:

Hipótesis	Diferencia o evidencia	Comprobación	Estado
Host incorrecto	Cambió la configuración del entorno	Verificar valor efectivo dentro del job	Descartada
PostgreSQL no arranca	Aparece connection refused	Revisar proceso y logs del servicio	Debilitada
PostgreSQL aún no está listo	El servicio se inicia antes de los tests	Comparar readiness y momento de conexión	Reforzada
Cambio de runner o imagen	Existe diferencia entre ejecución verde y roja	Comparar imagen y entorno efectivo	Pendiente

La corrección debería llegar después del diagnóstico, no sustituirlo. Cuando una hipótesis explica el fallo, encaja con las diferencias entre ejecuciones y sobrevive a las comprobaciones relevantes, ya existe una base razonable para aplicar un cambio concreto y volver a ejecutar el pipeline para verificar su efecto.

Conclusiones

Investigar un pipeline CI/CD fallido con IA no consiste en encontrar una respuesta convincente al primer intento. El punto de partida más útil es comparar la última ejecución correcta con la primera fallida para identificar qué cambió y utilizar esas diferencias como evidencia: configuración, variables, dependencias, servicios, runner o imagen de ejecución.

ChatGPT, Claude o Gemini pueden ayudar a convertir ese contexto en hipótesis comprobables y ordenar qué revisar primero. Cada prueba debería reducir la incertidumbre, descartar causas o reforzar una explicación concreta, no introducir cambios simplemente porque parecen razonables.

La IA acelera el diagnóstico, pero la corrección debe llegar después de la evidencia. Cuando una hipótesis explica el fallo, encaja con los cambios entre ejecuciones y supera las comprobaciones relevantes, ya existe una base sólida para intervenir y verificar el resultado con una nueva ejecución del pipeline.