Automatizar la revisión de código de Magento con GitHub Actions

Revisar pull requests de Magento a mano, a lo largo de una docena de repositorios de clientes, es mucho trabajo repetido: ¿lleva el PR el título con la clave de Jira, están registrados los módulos nuevos, el diff hace saltar PHPCS, hay algún var_dump que alguien olvidó. Es trabajo importante, pero la mayor parte es mecánico — y el trabajo mecánico es para lo que existe la CI. Así que construí un motor de revisión de código reutilizable en GitHub Actions y lo publiqué como código abierto: github.com/zynqa/code-review-engine .

El pipeline

Cada pull request pasa por un único workflow reutilizable. Cada etapa es opcional y se activa por repositorio, y la puerta de merge final solo evalúa las comprobaciones que hayas activado.

Un workflow reutilizable, seis etapas opcionales. La puerta solo exige lo que hayas activado.

Un workflow, cada repositorio

El motor es un único workflow reutilizable. Un repo consumidor no copia la lógica de CI — llama al motor y elige qué comprobaciones ejecutar:

# .github/workflows/code-review.yml
name: Code Review
on:
  pull_request:
    types: [opened, edited, synchronize, reopened]

jobs:
  review:
    uses: zynqa/code-review-engine/.github/workflows/review.yml@main
    with:
      magento-version: "2.4.5-p5"
      jira-project-key: "PROJ"
      enable-pr-validation: true
      enable-module-registration: true
      enable-static-analysis: true
      enable-ai-review: false
      enable-tests: false
    secrets: inherit

Como todos apuntan a @main, arreglar una regla o añadir una comprobación en el motor llega a cada repositorio en su siguiente PR — sin subir versiones en una docena de proyectos.

Apunta cada repo a @main una vez; cada uno mantiene su propio perfil de comprobaciones.

Primero determinista, después IA

El orden importa. Las comprobaciones baratas y deterministas se ejecutan primero y detectan los problemas mecánicos gratis, así la revisión con IA (la única etapa que cuesta dinero y tiempo) se dedica al criterio, no a cosas que un linter ya sabe.

El análisis estático se ejecuta solo sobre los ficheros que cambió el PR, no sobre todo el repositorio — rápido, y los comentarios caen en las líneas que realmente tocaste. Ejecuta PHPCS, PHPStan y PHPMD, y publica anotaciones de GitHub, comentarios de revisión en línea y un resumen fijo con conteos por herramienta. Además de los sniffs estándar de Magento, el motor incluye reglas de PHPCS propias de Zynqa:

• declare(strict_types=1); es obligatorio
• los helpers de Magento deben ser stateless
• sin superglobales y sin global
• sin eval, die, var_dump, print_r, error_log
• sin uso directo de ObjectManager
• sin Setup/InstallSchema.php obsoleto
• reglas de herencia de controladores admin / ADMIN_RESOURCE
• sin lógica de presentación en línea en .phtml

Aquí tienes algunas de esas reglas saltando como comentarios de revisión en línea en un pull request real — pulsa en cualquiera para ampliarla:

El revisor con IA, con contexto real

Solo cuando pasan las comprobaciones mecánicas se ejecuta el revisor Claude — y no ve solo el diff. Extrae el contexto que un revisor humano abriría en otras pestañas: el ticket de Jira, las páginas de Confluence relacionadas y los hilos de Slack, junto al propio PR de GitHub. Esa es la diferencia entre «este método es largo» y «esto no hace lo que pedía el ticket».

El revisor lee el ticket, la documentación y el chat — no solo el diff — y luego comenta en las líneas exactas.

Si la revisión con IA está activada sin un ANTHROPIC_API_KEY, el job falla de forma explícita en lugar de saltarse en silencio — una comprobación que crees que se ejecuta debería ejecutarse de verdad.

La puerta de merge

Cuando pasan las comprobaciones activadas, la última etapa puede aprobar el PR como github-actions[bot], elegir un método de merge permitido, actualizar la rama si está por detrás, y fusionar — recurriendo al auto-merge nativo de GitHub cuando una regla bloquea el merge directo. Y lo importante: la puerta solo evalúa las comprobaciones que un repo activó, así que un repo de módulo que solo ejecuta análisis estático no queda a merced de una revisión con IA que nunca habilitó.

Perfiles

Dos perfiles de toggles cubren la mayoría de repos. Un repo de aplicación Magento suele ejecutar convenciones de PR + registro de módulos + análisis estático + auto-aprobación; un repo de módulo independiente normalmente ejecuta solo análisis estático (y quizá tests). Ambos son un puñado de inputs true/false — sin pipelines bifurcados.

Pruébalo

Es de código abierto: github.com/zynqa/code-review-engine . Copia la plantilla del proyecto en el .github/workflows/ de un repo, ajusta los inputs, mantén secrets: inherit, y tu siguiente pull request recibe el tratamiento completo. Empieza solo con el análisis estático — es la mayor señal con cero configuración — y ve activando el resto según vayas confiando.