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

1. Enunciato del Problema

L'Integrazione Continua (CI) è centrale nello sviluppo software moderno, garantendo la correttezza a livello di repository attraverso flussi di lavoro multistadio. Tuttavia, la diagnosi e la riparazione dei fallimenti della CI rimangono una sfida significativa per i sistemi automatizzati. A differenza della riparazione tradizionale del codice, i fallimenti della CI coinvolgono spesso:

• Artefatti non di codice: Script di build, specifiche delle dipendenze, variabili d'ambiente e configurazioni dei flussi di lavoro.
• Log di esecuzione rumorosi: Log verbosi e multistadio in cui la causa radice è spesso oscurata o si trova in uno stadio diverso rispetto al sintomo.
• Ambienti dinamici: Fallimenti derivanti dalla risoluzione delle dipendenze, dalla deriva dell'ambiente o da incompatibilità della catena di strumenti.

Gli esistenti benchmark per la Riparazione Automatica dei Programmi (APR) (ad esempio SWE-bench, Defects4J) sono insufficienti per questo dominio perché:

1. Limitano le riparazioni al solo codice sorgente.
2. Si basano su oracoli incentrati sui test (passa/fallisce) piuttosto che sulla validazione completa della pipeline.
3. Presuppongono ambienti di esecuzione fissi e containerizzati.
4. Utilizzano input guidati da problemi invece che diagnosi guidate dai log.
5. Valutano su flussi di lavoro semplificati che mancano della complessità reale (ad esempio, esecuzione condizionale, dipendenze tra più job).

2. Metodologia: CI-Repair-Bench

Gli autori introducono CI-Repair-Bench, un benchmark su larga scala costruito da esecuzioni reali di GitHub Actions per colmare queste lacune.

Costruzione del Dataset

• Fonte: 103 repository Python attivamente mantenuti (selezionati in base al numero di stelle e all'attività recente).
• Scala: 567 istanze di fallimento della CI derivate da coppie di commit "da fallito a passato".
• Componenti per Istanza:
  1. Metadati del Repository: Proprietario, nome, ramo.
  2. Dettagli del Flusso di Lavoro CI: Configurazione YAML e passaggi di validazione.
  3. Log e Artefatti CI: Log di esecuzione dal job fallito.
  4. Coppia di Commit: Il commit fallito e il successivo commit passante più vicino.
  5. Patch di Verità Fondamentale: Una patch minima e validata derivata dalla coppia di commit, che isola solo le modifiche causalmente correlate al fallimento della CI.
• Tassonomia degli Errori: I fallimenti sono categorizzati in 12 tipi distinti, tra cui Formattazione del Codice, Linting, Errori di Sintassi, Errori di Runtime, Fallimenti dei Test, Problemi di Dipendenze, Errori di Configurazione ed Errori Ambientali.
• Validazione: La correttezza è valutata esclusivamente tramite ri-esecuzione completa di GitHub Actions sotto il flusso di lavoro originale (standardizzato). Una riparazione ha successo solo se l'intera pipeline passa senza introdurre nuovi fallimenti.

Framework di Riparazione di Riferimento

Per dimostrare l'utilizzo del benchmark, gli autori propongono una pipeline di riparazione agenziale della CI di riferimento composta da tre stadi:

1. Analisi dei Log CI: Utilizza una strategia iterativa basata su agenti LLM per suddividere, filtrare e riassumere i log rumorosi in un rapporto di fallimento strutturato.
2. Localizzazione del Guasto: Riduce lo spazio di ricerca selezionando i file modificati, affinando i candidati in base a prove causali ed eseguendo una localizzazione a livello di riga fine.
3. Generazione della Patch: Genera patch a livello di repository. Prioritizza correzioni deterministiche basate su strumenti (ad esempio, l'esecuzione di un linter) per le violazioni di regole e utilizza la modifica del codice basata su LLM per la logica complessa.

3. Contributi Chiave

1. CI-Repair-Bench: Il primo benchmark progettato specificamente per la riparazione di programmi a livello di repository e verificata dalla CI. Supporta modifiche ad artefatti non di codice e valida le riparazioni rispetto a pipeline CI complete piuttosto che a test isolati.
2. Pipeline di Riparazione di Riferimento: Un framework modulare che integra analisi dei log, localizzazione del guasto e generazione di patch, istanziato con quattro diversi Modelli Linguistici di Grande Dimensione (LLM) per stabilire le linee di base.
3. Analisi Empirica: Uno studio completo che caratterizza come l'efficacia della riparazione vari tra diversi modi di fallimento della CI e capacità dei modelli.

4. Risultati Sperimentali

Gli autori hanno valutato il framework di riferimento utilizzando quattro LLM: GPT-5-mini, DeepSeek-Coder, DeepSeek-Chat e GPT-4o-mini.

Prestazioni Complessive

• Tasso di Successo della Riparazione (Pass@1): Il modello con le prestazioni migliori (GPT-5-mini) ha raggiunto solo un 18,9% di successo. Il più basso è stato del 7,9%.
• Divario tra Localizzazione e Riparazione: Sebbene la localizzazione del guasto (accuratezza Top-1) fosse relativamente coerente tra i modelli (~42-45%), il successo finale della riparazione variava di oltre 2 volte. Ciò indica che identificare il file corretto è necessario ma insufficiente; generare la modifica minima corretta che soddisfi tutti gli stadi della CI è il principale collo di bottiglia.
• Applicazione della Patch vs. Successo CI: Circa il 73–89% delle patch applicate ha fallito la ri-esecuzione completa della CI, evidenziando la severità del benchmark rispetto alle valutazioni basate solo sui test.

Impatto della Strategia di Analisi dei Log

• Basato su Agenti vs. Recupero (BM25): Sostituire l'analisi dei log basata su agenti iterativi con una strategia di recupero BM25 leggera ha causato un crollo massiccio delle prestazioni.
  • Calo di Pass@1: È variato dal 28,0% al 75,9% tra i modelli.
  • Calo di Localizzazione: L'accuratezza Top-1 è scesa di 24–37 punti.
  • Conclusione: Un'analisi dei log accurata e basata sul ragionamento è critica per la riparazione della CI; il semplice recupero per parole chiave non riesce a catturare il contesto semantico necessario per la diagnosi.

Prestazioni per Tipo di Fallimento

Il successo della riparazione segue una chiara gerarchia a tre livelli basata sulla "località del segnale" dell'errore:

1. Alto Successo (Livello Superiore): Formattazione del Codice (35,5%) e Linting (17,8%). Questi hanno posizioni di errore esplicite nei log, permettendo correzioni dirette e deterministiche.
2. Successo Moderato (Livello Intermedio): Fallimenti dei test, errori di runtime ed errori di sintassi (10–13%).
3. Basso/Zero Successo (Livello Inferiore): Problemi di Dipendenze, Errori di Configurazione ed Errori Ambientali (<9% di successo, spesso 0%). Questi richiedono ragionamento tra file, contesto esterno e validazione iterativa che i singoli passaggi degli attuali LLM non possono fornire in modo affidabile.

5. Significato e Implicazioni

• Valutazione Realistica: CI-Repair-Bench espone i limiti degli attuali benchmark APR, che spesso sovrastimano le capacità di riparazione ignorando vincoli ambientali e di flusso di lavoro.
• Direzione di Ricerca: I risultati suggeriscono che i futuri sistemi di riparazione della CI devono andare oltre la generazione di codice in un singolo passaggio. Richiedono ragionamento consapevole del repository, analisi delle dipendenze e cicli di validazione iterativi per gestire fallimenti complessi e non localizzati.
• Divario Strumentale: Sebbene gli LLM siano efficaci per regole imposte dagli strumenti (formattazione/linting), faticano con i fallimenti "sistemici" (dipendenze, configurazione dell'ambiente), indicando la necessità di approcci ibridi che combinino LLM con strumenti specializzati di analisi statica e risoluzione delle dipendenze.
• Risorsa Aperta: Il benchmark, il dataset e il codice di riferimento sono disponibili pubblicamente, fornendo una base standardizzata per avanzare la ricerca sulla riparazione automatizzata nativa della CI.