AWS Builder Center

Builder Center

Mi pipeline falló y mi código no cambió: Pipeline Doctor con AWS

Cuando un pipeline falla y tu código no cambió, casi siempre cambió el entorno: una versión, una dependencia, la imagen del runner. Pipeline Doctor guarda la huella del entorno en cada run verde y, cuando algo falla, la compara con la última exitosa para decirte qué cambió. GitHub Actions, OIDC sin llaves, S3 y Bedrock opcional. Código abierto y paso a paso en video.

El problema: ayer verde, hoy rojo, mismo código...

Todos hemos vivido esto: el pipeline pasaba ayer, hoy falla y el commit es el mismo. Lo que cambió no está en tu repositorio. Salió una versión nueva de una dependencia, el runner de GitHub actualizó su imagen o se movió una etiqueta.
La mayoría de las herramientas que ayudan con un pipeline roto leen el log y adivinan un arreglo. Pero si el código no cambió, el arreglo no está en el código y adivinar a partir de un log de miles de líneas hace perder tiempo. Yo quería responder una sola pregunta: qué cambió entre la última vez que funcionó y hoy.

La idea: un historial clínico para tu pipeline

Pipeline Doctor piensa como un médico con historial. En cada run guarda una huella del entorno: las versiones de las herramientas conocidas, los paquetes instalados, el hash de los archivos de dependencias y la imagen del runner. Cuando un run falla, compara su huella con la del último run exitoso de la rama base y te devuelve una frase:
Tu código no cambió; cambió esto.
La comparación y los descartes los hace código determinístico, no un modelo. Si el código sí cambió, el informe lo dice y descarta la causa del entorno. Los modelos de lenguaje entran solo al final y de forma opcional, para redactar la explicación en lenguaje humano.

Cómo funciona: dos jobs y cuatro pasos

Diagrama de arquitectura de Pipeline Doctor: el job de test guarda la huella del entorno en S3 mediante un rol OIDC, y el job doctor la compara con la del último run exitoso, redacta el diagnóstico con Bedrock (opcional) y lo publica en el resumen del run y en el comentario del PR.
Dos jobs y cuatro pasos: guardar la huella, consultar el último run exitoso, redactar con IA y publicar el informe.
Pipeline Doctor son dos acciones compuestas de GitHub Actions dentro del mismo workflow. El job test instala y prueba tu app. Su último paso, la acción huella, corre siempre, incluso si el test falla. Si test falla, arranca el job doctor.
  1. Guardar la huella. La acción huella entra a AWS con OIDC y guarda la huella del run en un bucket privado de Amazon S3.
  2. Comparar. El job doctor lee el log, oculta los secretos y compara la huella actual con la del último run exitoso, que también está en S3.
  3. Redactar (opcional). Amazon Bedrock, con el modelo Amazon Nova Lite, recibe el resultado ya limpio y redacta la explicación en lenguaje humano. Sin Bedrock, el informe sale igual, en modo sin IA.
  4. Publicar. El informe aparece en el resumen del run y como comentario en el pull request.
Un ejemplo del informe: si el paso 2 encuentra que fechautil pasó de 1.0.0 a 1.1.0 y el código es el mismo, el informe te lo dice y te sugiere fijar la versión anterior.

Seguridad y costos: sin llaves, sin servidores

Un pipeline que habla con AWS no debería guardar llaves. Pipeline Doctor decide la seguridad en tres lugares:
  • Sin access keys. GitHub entra a AWS con OIDC. El rol pipeline-doctor-github solo puede ser asumido por los repositorios que listas en Terraform y sus credenciales duran una hora. Sus permisos se limitan a leer y escribir huellas en un prefijo del bucket y a invocar modelos Amazon Nova en Bedrock.
  • Log limpio. Antes de que el log llegue a Bedrock o se publique, se ocultan llaves de AWS, tokens, claves privadas y variables con nombres como password o secret. La huella usa una lista blanca: nunca se vuelcan todas las variables de entorno.
  • El modelo solo escribe texto. No ejecuta comandos ni abre pull requests. Si falla o no está disponible, el diagnóstico sigue funcionando.
Sobre costos: la infraestructura es un bucket de S3, un proveedor OIDC y un rol de IAM, sin servidores que mantener. El único costo variable es Bedrock, y es opcional. Con terraform destroy se borra todo.

Pruébalo en tu cuenta en tres pasos

Necesitas una cuenta de AWS, Terraform 1.6 o superior y el AWS CLI configurado.
  1. Crea la infraestructura. En la carpeta infra/terraform copia terraform.tfvars.example a terraform.tfvars, pon tu dueño/repo en github_repositories y ejecuta terraform init y terraform apply. Se crean 8 recursos: el bucket privado, el proveedor OIDC y el rol de IAM con permisos mínimos.
  2. Guarda dos variables en tu repositorio (Settings, Secrets and variables, Actions, pestaña Variables): PIPELINE_DOCTOR_ROLE_ARN con la salida rol_arn de Terraform y PIPELINE_DOCTOR_BUCKET con la salida bucket. Son variables y no secretos, porque con OIDC no hay llaves que proteger. Para activar la IA, agrega PIPELINE_DOCTOR_MODEL_ID, por ejemplo amazon.nova-lite-v1:0.
  3. Agrega a tu workflow la acción huella al final del job de pruebas (con if: always()) y un job doctor con la acción diagnostico, que corre solo cuando test falla.
La primera vez no hay con qué comparar: haz que el job pase una vez en la rama principal y desde ahí ya puede diagnosticar. En el repositorio hay dos “pacientes” de demostración: uno enfermo por una dependencia sin versión fija, y otro donde el código sí cambió, para ver cómo el informe descarta el entorno.

Qué sigue y dónde verlo

Esta es la versión cero: diagnostica y sugiere, no toca tu código. Lo que sigue es validar el arreglo en un sandbox antes de proponerlo, abrir un pull request con el parche, llevar una memoria de fallos con evaluaciones, soportar Node, Java y Docker, y llevar la misma idea a GitLab CI. El motor está separado de la plataforma, así que sumar otro CI es escribir un adaptador.
Si lo pruebas, cuéntame qué paciente te tocó.
Creado por Maika Esteves, ingeniera DevOps, @maikadevops .
# terraform# pipeline# ci-cd# amazon-bedrock# github
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article