CI-Repair-Bench: A Repository-Aware Benchmark for Automated Patch Validation via CI Workflows

1. Declaración del Problema

La Integración Continua (CI) es central en el desarrollo de software moderno, imponiendo la corrección a nivel de repositorio mediante flujos de trabajo de múltiples etapas. Sin embargo, diagnosticar y reparar fallos de CI sigue siendo un desafío significativo para los sistemas automatizados. A diferencia de la reparación de programas tradicional, los fallos de CI a menudo involucran:

• Artefactos no de código: Scripts de compilación, especificaciones de dependencias, variables de entorno y configuraciones de flujo de trabajo.
• Registros de ejecución ruidosos: Registros verbosos y de múltiples etapas donde la causa raíz suele estar oscurecida o ubicada en una etapa diferente a la del síntoma.
• Entornos dinámicos: Fallos que surgen de la resolución de dependencias, la deriva del entorno o incompatibilidades en la cadena de herramientas.

Los benchmarks existentes de Reparación Automática de Programas (APR) (por ejemplo, SWE-bench, Defects4J) son insuficientes para este dominio porque:

1. Restringen las reparaciones únicamente al código fuente.
2. Se basan en oráculos centrados en pruebas (aprobado/reprobado) en lugar de una validación completa del pipeline.
3. Asumen entornos de ejecución fijos y contenerizados.
4. Utilizan entradas impulsadas por problemas en lugar de diagnósticos impulsados por registros.
5. Evalúan sobre flujos de trabajo simplificados que carecen de complejidad del mundo real (por ejemplo, ejecución condicional, dependencias de múltiples trabajos).

2. Metodología: CI-Repair-Bench

Los autores presentan CI-Repair-Bench, un benchmark a gran escala construido a partir de ejecuciones reales de GitHub Actions para abordar estas brechas.

Construcción del Conjunto de Datos

• Fuente: 103 repositorios de Python mantenidos activamente (seleccionados según el número de estrellas y actividad reciente).
• Escala: 567 instancias de fallos de CI derivadas de pares de commits de "fallar a aprobar".
• Componentes por Instancia:
  1. Metadatos del Repositorio: Propietario, nombre, rama.
  2. Detalles del Flujo de Trabajo de CI: Configuración YAML y pasos de validación.
  3. Registros y Artefactos de CI: Registros de ejecución del trabajo fallido.
  4. Par de Commits: El commit que falló y el siguiente commit que aprobó más cercano.
  5. Parche de Verdad Terrenal: Un parche mínimo y validado derivado del par de commits, aislando solo los cambios causalmente relacionados con el fallo de CI.
• Taxonomía de Errores: Los fallos se categorizan en 12 tipos distintos, que incluyen Formato de Código, Linting, Errores de Sintaxis, Errores de Ejecución, Fallos de Pruebas, Problemas de Dependencias, Errores de Configuración y Errores de Entorno.
• Validación: La corrección se evalúa exclusivamente mediante re-ejecución completa de GitHub Actions bajo el flujo de trabajo original (estandarizado). Una reparación solo es exitosa si todo el pipeline aprueba sin introducir nuevos fallos.

Marco de Referencia de Reparación

Para demostrar el uso del benchmark, los autores proponen un pipeline de reparación agéntica de CI de referencia que consta de tres etapas:

1. Análisis de Registros de CI: Utiliza una estrategia iterativa basada en agentes de LLM para fragmentar, filtrar y resumir registros ruidosos en un informe de fallo estructurado.
2. Localización de Fallos: Reduce el espacio de búsqueda seleccionando archivos modificados, refinando candidatos basándose en evidencia causal y realizando una localización de línea a nivel fino.
3. Generación de Parches: Genera parches a nivel de repositorio. Prioriza correcciones deterministas basadas en herramientas (por ejemplo, ejecutar un linter) para violaciones de reglas y utiliza edición de código basada en LLM para lógica compleja.

3. Contribuciones Clave

1. CI-Repair-Bench: El primer benchmark diseñado específicamente para la reparación de programas a nivel de repositorio y verificada por CI. Soporta modificaciones a artefactos no de código y valida las reparaciones contra pipelines completos de CI en lugar de pruebas aisladas.
2. Pipeline de Reparación de Referencia: Un marco modular que integra análisis de registros, localización de fallos y generación de parches, instanciado con cuatro Grandes Modelos de Lenguaje (LLM) diferentes para establecer líneas base.
3. Análisis Empírico: Un estudio exhaustivo que caracteriza cómo varía la efectividad de la reparación a través de diferentes modos de fallo de CI y capacidades de los modelos.

4. Resultados Experimentales

Los autores evaluaron el marco de referencia utilizando cuatro LLM: GPT-5-mini, DeepSeek-Coder, DeepSeek-Chat y GPT-4o-mini.

Rendimiento General

• Tasa de Éxito de Reparación (Pass@1): El modelo con mejor rendimiento (GPT-5-mini) logró solo un 18.9% de éxito. El más bajo fue del 7.9%.
• Brecha entre Localización y Reparación: Mientras que la localización de fallos (precisión Top-1) fue relativamente consistente entre modelos (~42-45%), el éxito final de la reparación varió en más de 2x. Esto indica que identificar el archivo correcto es necesario pero insuficiente; generar el cambio mínimo correcto que satisfaga todas las etapas de CI es el principal cuello de botella.
• Aplicación de Parches vs. Éxito de CI: Aproximadamente el 73–89% de los parches aplicados fallaron en la re-ejecución completa de CI, destacando la rigurosidad del benchmark en comparación con evaluaciones solo de pruebas.

Impacto de la Estrategia de Análisis de Registros

• Basado en Agentes vs. Recuperación (BM25): Reemplazar el análisis de registros basado en agentes iterativos con una estrategia de recuperación BM25 ligera causó una caída masiva en el rendimiento.
  • Caída en Pass@1: Osciló entre 28.0% y 75.9% entre los modelos.
  • Caída en Localización: La precisión Top-1 disminuyó entre 24 y 37 puntos.
  • Conclusión: Un análisis de registros preciso y pesado en razonamiento es crítico para la reparación de CI; la recuperación simple por palabras clave no logra capturar el contexto semántico necesario para el diagnóstico.

Rendimiento por Tipo de Fallo

El éxito de la reparación sigue una jerarquía clara de tres niveles basada en la "localidad de la señal" del error:

1. Alto Éxito (Nivel Superior): Formato de Código (35.5%) y Linting (17.8%). Estos tienen ubicaciones de error explícitas en los registros, lo que permite correcciones directas y deterministas.
2. Éxito Moderado (Nivel Medio): Fallos de pruebas, errores de ejecución y errores de sintaxis (10–13%).
3. Bajo/Cero Éxito (Nivel Inferior): Problemas de Dependencias, Errores de Configuración y Errores de Entorno (<9% de éxito, a menudo 0%). Estos requieren razonamiento entre archivos, contexto externo y validación iterativa que los LLM de un solo paso actuales no pueden proporcionar de manera fiable.

5. Significado e Implicaciones

• Evaluación Realista: CI-Repair-Bench expone las limitaciones de los benchmarks actuales de APR, que a menudo sobreestiman las capacidades de reparación ignorando las restricciones del entorno y del flujo de trabajo.
• Dirección de Investigación: Los resultados sugieren que los futuros sistemas de reparación de CI deben ir más allá de la generación de código de un solo paso. Requieren razonamiento consciente del repositorio, análisis de dependencias y bucles de validación iterativa para manejar fallos complejos y no localizados.
• Brecha de Herramientas: Mientras que los LLM son efectivos para reglas impuestas por herramientas (formato/linting), luchan con fallos "sistémicos" (dependencias, configuración del entorno), lo que indica la necesidad de enfoques híbridos que combinen LLM con herramientas especializadas de análisis estático y resolución de dependencias.
• Recurso Abierto: El benchmark, el conjunto de datos y el código de referencia están disponibles públicamente, proporcionando una base estandarizada para avanzar en la investigación de reparación automatizada nativa de CI.