Automatiza tu revisor de PRs con GitHub Actions

Automatizar tu revisor de PRs con GitHub Actions convierte el trabajo manual de revisar código en un sistema de integración continua real. Si hasta ahora corrías el prompt revisor a mano y mirabas los reportes cuando te acordabas, aquí aprendes a transformarlo en infraestructura de equipo. Es para quien ya construyó un revisor de IA y quiere que se ejecute solo en cada pull request.

Todo lo que construimos hasta ahora vivía en nuestra máquina: corríamos el revisor a mano, ejecutábamos el triaje cuando nos acordábamos. Útil, sí, pero no un sistema. Y aquí viene lo interesante: pasar de ese trabajo artesanal a algo que se dispara solo.

Qué es un workflow de CI y cómo funciona con cada pull request

A partir de este punto, cada pull request contra Payments SOC pasa por un workflow de integración continua. La estructura es sencilla y siempre sigue el mismo patrón de cuatro piezas.

• Un trigger, que en este caso es cada pull request.
• Una entrada, que sería el diff con los cambios propuestos.
• Una acción, que para nosotros es correr el prompt revisor que hemos construido.
• Una salida, que es el veredicto en formato JSON.

Para orquestar todo esto usamos GitHub Actions [00:26], la herramienta que ejecuta automáticamente lo que definamos cada vez que se levante un PR.

¿Qué es un workflow de CI? Es un proceso automatizado que se dispara con un evento, como abrir un pull request, ejecuta una acción sobre una entrada y devuelve una salida. En este caso, corre tu revisor de IA sobre el diff y entrega un veredicto en JSON.

Por qué la decisión más importante del workflow es de política, no técnica

La parte crítica no es el código, sino definir qué hace tu revisor con cada hallazgo. Hay tres niveles de acción, y elegir cuál aplicar es una decisión de política de equipo [00:38].

• Bloquear: impide el merge hasta resolver. Resérvalo solo para reglas de alto acuerdo o alta severidad.
• Advertir: deja un comentario visible pero no frena el merge. Úsalo para hallazgos relevantes pero no críticos, o de acuerdo medio.
• Reportar: registra en silencio para análisis posterior.

Mezclar estos niveles con criterio evita que tu equipo se frustre con un revisor que bloquea todo o que ignore señales importantes.

Cómo proteger tus secrets y API keys al enviar diffs a la IA

Aquí hay un punto delicado que no puedes pasar por alto. Cuando tu revisor manda código a un modelo de IA, estás enviando diffs a un tercero, y eso exige control.

• Envía a la IA estrictamente el diff necesario, nada de más.
• Asegúrate de que el proveedor tenga una política de no retención de datos.
• Mantén control de quién revisó qué y de quién puede ver esos diffs.

¿Dónde guardo la API key en GitHub Actions? Nunca la inyectes en el proyecto. Debe quedar como un secret configurado en GitHub, de modo que el workflow la lea sin exponerla en el repositorio.

Esta gestión de secretos es lo que separa un experimento casero de una infraestructura confiable.

Cómo se organizan los archivos del workflow en GitHub

Para la demostración se prepararon dos ramas: una rama base, que aquí no es develop pero podría serlo, y una rama con los cambios [02:13]. El archivo clave es el YAML que vive dentro de GitHub Workflows.

Tenerlo en esa ubicación hace que GitHub lo reconozca automáticamente y ejecute su contenido en cada PR [02:32]. Su función principal es rutear otros archivos: le dice al sistema que busque el archivo del revisor de IA, define el formato de salida JSON esperado y contiene la referencia a la API key del vendor [02:47].

En el ejemplo se especifica incluso el modelo a usar. El vendor elegido fue OpenRouter [03:19], por ser gratuito y suficiente para probar, aunque puedes usar el que prefieras.

Qué contiene cada archivo del sistema

Además del YAML, hay dos piezas más que trabajan juntas [04:05].

• El prompt del revisor: idealmente la versión más completa e iterada que construiste en clases anteriores. En la demo se dejó una versión básica para que el modelo corra rápido, pero tú debes colocar tu revisor completo.
• El archivo de esquemas: define la estructura JSON que esperas como salida. El workflow ya sabe rutear y decirle al modelo qué formato debe tener [04:38].

La recomendación es explorar estos archivos y adaptarlos a tu conveniencia.

¿Por qué separar el prompt del esquema de salida? Porque mantiene el prompt enfocado en las reglas de revisión, mientras el esquema controla la estructura de la respuesta. El YAML conecta ambos y garantiza un JSON consistente.

Qué evitar al desplegar tu revisor automatizado en el equipo

Una vez creado el pull request con las dos ramas preparadas, título, descripción y un cambio sencillo, el revisor deja de ser artesanal y se vuelve infraestructura de equipo [05:07].

La tentación natural es encender el modo bloqueante para todo el mundo de inmediato. No lo hagas todavía. Bloquear todo puede ser problemático en los equipos de desarrollo y romper el ritmo de trabajo.

Los tres pilares que debes cuidar al desplegar son:

• Secrets bien gestionados fuera del repositorio.
• Login de auditoría para saber quién revisó qué.
• Control estricto de qué diffs viajan a un tercero.

¿Cómo activarías tú el modo bloqueante sin frenar la velocidad de tu equipo? Cuéntame en los comentarios cómo lo aplicarías en tu flujo de trabajo.