💻 computer science

Is this Build Failure Related to my Patch? An Empirical Study of Unrelated Build Failures in Continuous Integration

Questo studio empirico analizza 77.354 fallimenti di build CI in sette progetti Apache per quantificare lo sforzo degli sviluppatori sprecato su fallimenti non correlati e dimostra che modelli di apprendimento semi-supervisionato Positive and Unlabeled (PU), che utilizzano caratteristiche come la latenza CI e i pattern di errore, possono prevedere efficacemente tali fallimenti non azionabili per aiutare gli sviluppatori a dare priorità ai loro sforzi di debug.

Autori originali: Andie Huang, Daniel Alencar da Costa, Grant Dick, Mariam El Mezouar

Pubblicato 2026-05-08

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Andie Huang, Daniel Alencar da Costa, Grant Dick, Mariam El Mezouar

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di essere uno chef che lavora in una cucina molto affollata e caotica (questo è l'ambiente di Continuous Integration). Ogni pochi minuti arriva un nuovo ordine (un push di codice), e la cucina inizia automaticamente a preparare un pasto di prova per verificare se i nuovi ingredienti funzionano.

A volte, il pasto di prova brucia o ha un sapore terribile. Di solito, questo significa che lo chef che ha appena aggiunto i nuovi ingredienti ha commesso un errore. Ma a volte, l'allarme antincendio suona perché lo chef precedente ha lasciato acceso il fornello, o il forno si è rotto, o qualcun altro ha fatto cadere un vassoio nella stanza accanto. Questo è ciò che il documento definisce un "Fallimento di Build Non Correlato".

Il problema è che lo chef che ha appena aggiunto i nuovi ingredienti non sa perché il pasto è fallito. Passa ore (il documento indica una mediana di 4 ore) a controllare freneticamente le proprie spezie e i propri coltelli, cercando di dimostrare: "Non sono stato io!". Questo spreca molto tempo e causa stress.

Cosa hanno fatto i ricercatori

Gli autori (un team di ricercatori) hanno deciso di indagare su questo caos in cucina. Hanno esaminato 77.354 "pasti bruciati" (fallimenti di build) provenienti da 7 grandi progetti di software open source (come Apache Hadoop e HBase).

Il lavoro da detective: Hanno letto manualmente migliaia di commenti lasciati dagli sviluppatori dopo un fallimento. Hanno cercato frasi come "questo non è correlato al mio cambiamento" o "non correlato". Hanno trovato circa 10.300 casi in cui gli sviluppatori hanno esplicitamente dichiarato: "Questo fallimento non è colpa mia".
L'intervista: Hanno selezionato un campione più piccolo e rappresentativo di 371 di questi casi "non è colpa mia" e li hanno analizzati come un detective analizza una scena del crimine. Si sono chiesti: Perché gli sviluppatori hanno detto che non era colpa loro?
- Le scoperte: Le ragioni più comuni erano:
  - Test non correlati: Il test fallito stava effettivamente verificando qualcosa di una parte diversa della cucina, non il nuovo ingrediente.
  - Interferenza esterna: Qualcosa fuori dalla cucina è cambiato (come un fornitore che consegna farina scadente a tutti).
  - Non riproducibile: L'incendio è accaduto una volta, ma quando hanno provato a preparare il pasto di nuovo, era tutto a posto (forse un picco di tensione casuale).
  - Il gruppo "Non specificato": Una grossa fetta (35%) delle volte, gli sviluppatori dicevano semplicemente "Non sono stato io" senza spiegare perché.

La soluzione: un "Assistente Intelligente"

Poiché gli sviluppatori non possono sempre spiegare perché un fallimento è non correlato immediatamente, i ricercatori hanno costruito un Assistente Intelligente (un modello di apprendimento automatico) per indovinare al posto loro.

Hanno utilizzato una tecnica speciale chiamata PU Learning (Apprendimento Positivo-Non Etichettato).

L'analogia: Immagina di voler insegnare a un cane a trovare un tipo specifico di palla. Hai alcune palle che sai essere del tipo giusto (gli esempi Positivi). Ma hai un enorme mucchio di palle miste in cui non sai quali siano del tipo giusto e quali no (il mucchio Non Etichettato). Non puoi semplicemente dire "tutto il resto è una palla sbagliata" perché alcune di esse potrebbero effettivamente essere del tipo giusto, semplicemente non le hai ancora controllate.
Come ha funzionato: I ricercatori hanno fornito al modello i "fallimenti non correlati noti" e il "mucchio sconosciuto". Il modello ha imparato a individuare schemi che suggeriscono che un fallimento è probabilmente non correlato, anche senza un'etichetta chiara.

Quanto era bravo l'assistente?

Il modello è stato testato sugli stessi 7 progetti.

Era molto bravo in precisione (quando diceva "Non è colpa tua", di solito aveva ragione, circa il 70% - 88% delle volte).
Era bravo nel ricordo (ha trovato la maggior parte dei fallimenti non correlati, anche se ne ha persi alcuni).
Ha superato significativamente il caso o regole semplici.

Le "Piste" usate dal modello

I ricercatori hanno trovato tre piste principali che hanno aiutato il modello a decidere se un fallimento era non correlato:

Il divario temporale (Latenza CI): Se uno sviluppatore ha inviato del codice e ha aspettato molto tempo prima di attivare la build, è più probabile che qualcun altro abbia rotto la cucina nel frattempo.
L'errore "Déjà Vu": Se il messaggio di errore assomiglia esattamente a uno che è accaduto di recente, è probabilmente una ripetizione di un vecchio problema, non uno nuovo causato dallo chef attuale.
La chiacchierata: Se ci sono molti commenti sul problema prima che il fallimento accadesse, suggerisce che il problema è complesso e coinvolge probabilmente il lavoro di altre persone, non solo l'invio corrente.

La conclusione

Il documento conclude che utilizzando questo "Assistente Intelligente", gli sviluppatori possono ottenere un rapido indizio: "C'è un'alta probabilità che questo fallimento non sia colpa tua."

Questo non significa che possano ignorare il problema, ma dice loro: "Non passare 4 ore a controllare il tuo codice. Forse controlla il forno o chiedi all'altro chef". Questo li aiuta a smettere di perdere tempo su falsi allarmi e a tornare a cucinare (programmare) più velocemente.

Nota importante: Il documento si concentra interamente sull'identificazione di questi fallimenti nei progetti software. Non afferma che questo metodo funzioni per la diagnosi medica, il trading finanziario o qualsiasi altro campo al di fuori dello sviluppo software. È strettamente uno strumento per i team software per gestire il proprio caos in "cucina".

Riepilogo Tecnico: Questo Fallimento della Build è Correlato alla mia Patch? Uno Studio Empirico sui Fallimenti di Build Non Correlati nell'Integrazione Continua

1. Enunciato del Problema

Negli ambienti di Integrazione Continua (CI), più sviluppatori spesso inviano codice in modo concorrente. Questa concorrenza può portare a fallimenti di build non correlati: fallimenti legittimi che si verificano durante il processo CI ma che non sono causati dall'invio di codice corrente. A differenza dei test flaky (che sono non deterministici), questi fallimenti sono reali ma derivano da fattori quali rotture a cascata da invii precedenti, problemi di configurazione, dipendenze esterne o instabilità ambientale.

Il problema centrale è che gli sviluppatori devono dedicare tempo significativo all'indagine su questi fallimenti per determinare se ne sono responsabili. I dati empirici degli autori rivelano che gli sviluppatori investono una mediana di 4 ore per confermare se un fallimento non è correlato alle loro modifiche. Questo "tempo sprecato" crea un onere, potenzialmente portando a "fatica da notifica" e a una ridotta adesione alle migliori pratiche CI se gli sviluppatori percepiscono le build come costantemente fallite a causa di fattori fuori dal loro controllo.

2. Metodologia

Lo studio adotta un approccio a metodi misti che coinvolge data mining, analisi qualitativa e apprendimento automatico semi-supervisionato su sette progetti della Apache Software Foundation (ASF) (AMBARI, HADOOP, HBASE, HDDS, HDFS, HIVE, YARN).

2.1 Raccolta Dati ed Etichettatura Euristica

Dataset: Gli autori hanno estratto 77.354 fallimenti di build CI dai report delle issue di JIRA.
Etichettatura Basata su Euristiche (HL): Per identificare potenziali fallimenti non correlati, hanno sviluppato un'euristica basata su parole chiave. Hanno cercato termini specifici nei commenti degli sviluppatori successivi a un fallimento di build (ad esempio, "non correlato", "non pertinente", "irrilevante", "non connesso").
Set Iniziale: Questo processo ha identificato 10.316 potenziali fallimenti di build non correlati.
Cura del Campione: Da questo insieme, un campione statisticamente rappresentativo di 371 fallimenti realmente non correlati è stato curato manualmente (livello di confidenza del 95%, intervallo di confidenza del 5%) attraverso un rigoroso processo di analisi documentale che coinvolgeva più codificatori.

2.2 Analisi Documentale (Qualitativa)

Gli autori hanno eseguito un'analisi tematica sui 371 fallimenti curati per comprendere perché gli sviluppatori li consideravano non correlati. Ciò ha comportato:

Trattare i log CI e i commenti degli sviluppatori come documenti digitali.
Codifica induttiva per generare temi.
Controlli di affidabilità inter-valutatore (punteggi di Kappa di Cohen da 0,76 a 0,77).

2.3 Ingegneria delle Caratteristiche

Sulla base dei risultati qualitativi, gli autori hanno estratto 33 caratteristiche da tre dimensioni:

Livello Report dell'Issue: Priorità, issue parallele, collegamenti tra progetti, stato duplicato, ecc.
Livello Commento: Numero di commenti precedenti, messaggi di errore condivisi con fallimenti precedenti, numero di fallimenti simili.
Livello Invio: Latenza CI (tempo dall'invio della patch all'innesco della build), presenza di patch di codice/configurazione, righe aggiunte/modificate/eliminate nei file sorgente e di configurazione.

Preprocessing: Le caratteristiche collineari sono state rimosse utilizzando la correlazione di rango di Spearman ( $|\rho| \ge 0,7$ ) e l'analisi di ridondanza ( $R^2 > 0,9$ ) su base per progetto.

2.4 Modellazione: Apprendimento Positivo-Non Etichettato (PU)

Riconoscendo che il dataset è sbilanciato e che le istanze "negative" (fallimenti correlati all'invio) non possono essere etichettate in modo affidabile (poiché gli sviluppatori potrebbero non dichiarare esplicitamente che un fallimento è correlato), gli autori hanno adottato un framework di apprendimento Positivo-Non Etichettato (PU).

Classe Positiva: Fallimenti non correlati confermati manualmente (371 campioni, estesi a 700 per l'addestramento).
Classe Non Etichettata: Tutti gli altri fallimenti di build (potenzialmente contenenti sia fallimenti correlati che non correlati).
Algoritmi: Sono state implementate due varianti del classificatore Elkan & Noto:
1. Elkan & Noto Classico: Assume che i dati non etichettati siano una miscela di positivi e negativi.
2. Elkan & Noto Ponderato: Assegna pesi agli esempi non etichettati per tenere conto della possibilità che contengano istanze positive.
Assunzione: Lo studio valida l'assunzione SCAR (Selected Completely At Random), garantendo che le istanze positive etichettate siano un campione rappresentativo di tutte le istanze positive.
Valutazione: I modelli sono stati valutati utilizzando la validazione incrociata a 10 fold e una strategia di validazione incrociata tra progetti "leave-one-project-out". Le metriche includevano Precisione, Recall, F1-score e AUC.

3. Contributi Chiave

3.1 Caratterizzazione Empirica

Costo Temporale: Quantificazione del tempo mediano che gli sviluppatori dedicano alla verifica dei fallimenti non correlati come 4 ore.
Cause Radice: Identificazione di sette temi che spiegano perché i fallimenti sono considerati non correlati:
1. Test Non Correlati (20%): Fallimenti in classi di test non correlate all'invio corrente.
2. Non Specificato dallo Sviluppatore (34,86%): Gli sviluppatori indicano "non correlato" senza contesto.
3. Interferenza Esterna (19,73%): Problemi con librerie o dipendenze di terze parti.
4. Non Riproducibile (17,03%): Problemi infrastrutturali transienti (rete, disco, timeout).
5. Commit Concorrenti, Problemi di Configurazione e Impatto Ambientale.

3.2 Modellazione Predittiva

Sviluppo del primo approccio semi-supervisionato per prevedere automaticamente i fallimenti di build non correlati.
Dimostrazione che i modelli Elkan & Noto Ponderati superano costantemente i baseline (Random, Positivo Costante e corrispondenza euristica dei messaggi di errore).
Prestazioni:
- AUC: Variato da 0,63 a 0,97 tra i progetti.
- Precisione: Variata da 0,70 a 0,88.
- Recall: Variata da 0,30 a 1,00.
- F1-Score: Variato da 0,44 a 0,91.
Generalizzazione: I modelli hanno mantenuto prestazioni robuste nella validazione tra progetti, con la variante Ponderata che mostra miglioramenti significativi nella precisione (guadagni dal 13% al 24%) rispetto alla variante Classica.

3.3 Importanza delle Caratteristiche

L'analisi dell'importanza delle caratteristiche tramite permutazione ha rivelato gli indicatori più influenti per i fallimenti non correlati:

Latenza CI: Il tempo tra l'invio della patch e l'invio che innesca la build. Una latenza più lunga aumenta la probabilità di fallimenti non correlati.
Messaggi di Errore Simili: Se il fallimento corrente condivide un messaggio di errore con fallimenti recenti (indicando rotture a cascata).
Numero di Commenti Precedenti: Il volume di discussione precedente al fallimento, che può indicare contesti complessi e multi-issue.

4. Significato e Affermazioni

Il paper afferma che il suo contributo principale è fornire un framework semi-supervisionato per assistere gli sviluppatori nel triage dei fallimenti di build. Prevedendo la probabilità che un fallimento non sia correlato all'invio corrente, lo strumento mira a:

Ridurre lo Sforzo degli Sviluppatori: Consentire agli sviluppatori di saltare l'indagine sulle modifiche al codice quando un fallimento è probabilmente non correlato, concentrandosi invece sull'infrastruttura o sul riavvio della build.
Migliorare il Processo Decisionale: Aiutare i team a decidere se procedere con l'unione di un contributo nonostante un fallimento di build.
Identificare Problemi Sistemici: Predizioni ripetute di fallimenti non correlati possono segnalare configurazioni errate, problemi di rete infrastrutturale o problemi di dipendenza che richiedono monitoraggio sistematico.

Gli autori affermano esplicitamente che il loro obiettivo non è raggiungere una generalizzabilità perfetta su tutti i domini software immediatamente, ma dimostrare la fattibilità di questo approccio nell'identificare fallimenti non correlati all'interno di ecosistemi CI maturi. Sottolineano che il loro lavoro completa la ricerca esistente sui test flaky e sulla previsione generale degli esiti delle build, mirando a una classe specifica e spesso trascurata di fallimenti che confondono gli sviluppatori in ambienti di sviluppo concorrente.