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

1. Declaração do Problema

A Integração Contínua (CI) é central para o desenvolvimento de software moderno, impondo correção ao nível do repositório por meio de workflows multiestágio. No entanto, diagnosticar e reparar falhas de CI permanece um desafio significativo para sistemas automatizados. Diferentemente do reparo de programas tradicional, as falhas de CI frequentemente envolvem:

• Artefatos não-código: Scripts de build, especificações de dependências, variáveis de ambiente e configurações de workflow.
• Logs de execução ruidosos: Logs verbosos e multiestágio onde a causa raiz é frequentemente obscurecida ou localizada em um estágio diferente do sintoma.
• Ambientes dinâmicos: Falhas decorrentes de resolução de dependências, deriva de ambiente ou incompatibilidades de cadeia de ferramentas.

Os benchmarks existentes de Reparo Automatizado de Programas (APR) (por exemplo, SWE-bench, Defects4J) são insuficientes para este domínio porque eles:

1. Restringem reparos apenas ao código-fonte.
2. Baseiam-se em oráculos centrados em testes (passar/falhar) em vez de validação completa do pipeline.
3. Assumem ambientes de execução fixos e containerizados.
4. Utilizam entradas orientadas a issues em vez de diagnóstico orientado a logs.
5. Avaliam em workflows simplificados que carecem de complexidade do mundo real (por exemplo, execução condicional, dependências de múltiplos jobs).

2. Metodologia: CI-Repair-Bench

Os autores introduzem o CI-Repair-Bench, um benchmark de grande escala construído a partir de execuções reais do GitHub Actions para abordar essas lacunas.

Construção do Conjunto de Dados

• Fonte: 103 repositórios Python mantidos ativamente (selecionados com base na contagem de estrelas e atividade recente).
• Escala: 567 instâncias de falha de CI derivadas de pares de commits "falhar-para-passar".
• Componentes por Instância:
  1. Metadados do Repositório: Proprietário, nome, branch.
  2. Detalhes do Workflow de CI: Configuração YAML e etapas de validação.
  3. Logs e Artefatos de CI: Logs de execução do job falho.
  4. Par de Commits: O commit falho e o próximo commit de sucesso mais próximo.
  5. Patch de Verdade Terrena: Um patch mínimo e validado derivado do par de commits, isolando apenas as mudanças causalmente relacionadas à falha de CI.
• Taxonomia de Erros: As falhas são categorizadas em 12 tipos distintos, incluindo Formatação de Código, Linting, Erros de Sintaxe, Erros de Runtime, Falhas de Teste, Problemas de Dependência, Erros de Configuração e Erros de Ambiente.
• Validação: A correção é avaliada exclusivamente por meio da reexecução completa do GitHub Actions sob o workflow original (padronizado). Um reparo é considerado bem-sucedido apenas se todo o pipeline passar sem introduzir novas falhas.

Framework de Reparo de Referência

Para demonstrar o uso do benchmark, os autores propõem um pipeline de reparo agênico de CI de referência consistindo em três etapas:

1. Análise de Logs de CI: Utiliza uma estratégia iterativa baseada em agentes com LLM para fragmentar, filtrar e resumir logs ruidosos em um relatório de falha estruturado.
2. Localização de Falhas: Reduz o espaço de busca selecionando arquivos alterados, refinando candidatos com base em evidências causais e realizando localização de linha em nível fino.
3. Geração de Patch: Gera patches ao nível do repositório. Prioriza correções determinísticas baseadas em ferramentas (por exemplo, executar um linter) para violações de regras e utiliza edição de código baseada em LLM para lógica complexa.

3. Principais Contribuições

1. CI-Repair-Bench: O primeiro benchmark projetado especificamente para reparo de programas ao nível do repositório e verificado por CI. Suporta modificações em artefatos não-código e valida reparos contra pipelines de CI completos em vez de testes isolados.
2. Pipeline de Reparo de Referência: Um framework modular integrando análise de logs, localização de falhas e geração de patches, instanciado com quatro Grandes Modelos de Linguagem (LLMs) diferentes para estabelecer baselines.
3. Análise Empírica: Um estudo abrangente caracterizando como a eficácia do reparo varia entre diferentes modos de falha de CI e capacidades de modelos.

4. Resultados Experimentais

Os autores avaliaram o framework de referência utilizando quatro LLMs: GPT-5-mini, DeepSeek-Coder, DeepSeek-Chat e GPT-4o-mini.

Desempenho Geral

• Taxa de Sucesso de Reparo (Pass@1): O modelo de melhor desempenho (GPT-5-mini) alcançou apenas 18,9% de sucesso. O menor foi 7,9%.
• Lacuna entre Localização e Reparo: Embora a localização de falhas (precisão Top-1) fosse relativamente consistente entre os modelos (~42-45%), o sucesso final do reparo variou em mais de 2x. Isso indica que identificar o arquivo correto é necessário, mas insuficiente; gerar a mínima mudança correta que satisfaça todas as etapas de CI é o principal gargalo.
• Aplicação de Patch vs. Sucesso de CI: ~73–89% dos patches aplicados falharam na reexecução completa do CI, destacando a rigidez do benchmark em comparação com avaliações baseadas apenas em testes.

Impacto da Estratégia de Análise de Logs

• Baseado em Agente vs. Recuperação (BM25): Substituir a análise de logs iterativa baseada em agente por uma estratégia de recuperação BM25 leve causou uma queda massiva no desempenho.
  • Queda de Pass@1: Variou de 28,0% a 75,9% entre os modelos.
  • Queda de Localização: A precisão Top-1 caiu 24–37 pontos.
  • Conclusão: Uma análise de logs precisa e rica em raciocínio é crítica para o reparo de CI; a recuperação simples por palavras-chave falha em capturar o contexto semântico necessário para o diagnóstico.

Desempenho por Tipo de Falha

O sucesso do reparo segue uma hierarquia clara de três níveis baseada na "localidade do sinal" do erro:

1. Alto Sucesso (Top Tier): Formatação de Código (35,5%) e Linting (17,8%). Estes possuem localizações de erro explícitas nos logs, permitindo correções diretas e determinísticas.
2. Sucesso Moderado (Middle Tier): Falhas de teste, erros de runtime e erros de sintaxe (10–13%).
3. Baixo/Zero Sucesso (Bottom Tier): Problemas de Dependência, Erros de Configuração e Erros de Ambiente (<9% de sucesso, frequentemente 0%). Estes exigem raciocínio entre arquivos, contexto externo e validação iterativa que os LLMs atuais de passagem única não podem fornecer de forma confiável.

5. Significado e Implicações

• Avaliação Realista: O CI-Repair-Bench expõe as limitações dos benchmarks atuais de APR, que frequentemente superestimam as capacidades de reparo ao ignorar restrições de ambiente e workflow.
• Direção de Pesquisa: Os resultados sugerem que futuros sistemas de reparo de CI devem ir além da geração de código de passagem única. Eles exigem raciocínio consciente do repositório, análise de dependências e loops de validação iterativa para lidar com falhas complexas e não localizadas.
• Lacuna de Ferramentas: Embora os LLMs sejam eficazes para regras impostas por ferramentas (formatação/linting), eles lutam com falhas "sistêmicas" (dependências, configuração de ambiente), indicando a necessidade de abordagens híbridas que combinem LLMs com ferramentas especializadas de análise estática e resolução de dependências.
• Recurso Aberto: O benchmark, o conjunto de dados e o código de referência estão publicamente disponíveis, fornecendo uma base padronizada para avançar a pesquisa em reparo automatizado nativo de CI.