💻 computer science

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

Cette étude empirique analyse 77 354 échecs de construction CI répartis sur sept projets Apache afin de quantifier l'effort développeur gaspillé sur des échecs sans rapport et démontre que des modèles d'apprentissage semi-supervisé à partir de données positives et non étiquetées (PU), exploitant des caractéristiques telles que la latence CI et les motifs d'erreur, peuvent prédire efficacement ces échecs non actionnables pour aider les développeurs à prioriser leurs efforts de débogage.

Auteurs originaux : Andie Huang, Daniel Alencar da Costa, Grant Dick, Mariam El Mezouar

Publié 2026-05-08

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Andie Huang, Daniel Alencar da Costa, Grant Dick, Mariam El Mezouar

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un chef travaillant dans une cuisine très animée et chaotique (c'est l'environnement d'Intégration Continue). Toutes les quelques minutes, une nouvelle commande arrive (un push de code), et la cuisine commence automatiquement à préparer un plat-test pour vérifier si les nouveaux ingrédients fonctionnent.

Parfois, le plat-test brûle ou a un goût terrible. Habituellement, cela signifie que le chef qui vient d'ajouter les nouveaux ingrédients a fait une erreur. Mais parfois, l'alarme incendie se déclenche parce que le précédent chef a laissé le feu allumé, ou que le four est tombé en panne, ou qu'une autre personne a fait tomber un plateau dans la pièce voisine. C'est ce que l'article appelle un « Échec de construction sans rapport ».

Le problème est que le chef qui vient d'ajouter les nouveaux ingrédients ne sait pas pourquoi le plat a échoué. Il passe des heures (l'article indique une médiane de 4 heures) à vérifier frénétiquement ses propres épices et couteaux, essayant de prouver : « Ce n'était pas moi ! » Cela gaspille beaucoup de temps et cause du stress.

Ce que les chercheurs ont fait

Les auteurs (une équipe de chercheurs) ont décidé d'enquêter sur ce chaos de cuisine. Ils ont examiné 77 354 « plats brûlés » (échecs de construction) provenant de 7 grands projets logiciels open source (comme Apache Hadoop et HBase).

Le travail d'enquête : Ils ont lu manuellement des milliers de commentaires laissés par les développeurs après un échec. Ils ont recherché des phrases comme « ceci n'est pas lié à ma modification » ou « sans rapport ». Ils ont trouvé environ 10 300 cas où les développeurs ont explicitement déclaré : « Cet échec n'est pas de ma faute. »
L'entretien : Ils ont sélectionné un échantillon plus petit et représentatif de 371 de ces cas « pas de ma faute » et les ont analysés comme un détective analysant une scène de crime. Ils se sont demandé : Pourquoi les développeurs ont-ils dit que ce n'était pas de leur faute ?
- Les découvertes : Les raisons les plus courantes étaient :
  - Tests sans rapport : Le test qui a échoué vérifiait en réalité quelque chose provenant d'une autre partie de la cuisine, et non le nouvel ingrédient.
  - Interférence externe : Quelque chose en dehors de la cuisine a changé (comme un fournisseur livrant de la farine de mauvaise qualité à tout le monde).
  - Non reproductible : L'incendie s'est produit une fois, mais lorsqu'ils ont essayé de préparer à nouveau le plat, tout allait bien (peut-être une surtension électrique aléatoire).
  - Le groupe « Non spécifié » : Une énorme partie (35 %) du temps, les développeurs disaient simplement « Ce n'est pas moi » sans expliquer pourquoi.

La solution : un « Assistant intelligent »

Puisque les développeurs ne peuvent pas toujours expliquer pourquoi un échec est sans rapport immédiatement, les chercheurs ont construit un Assistant intelligent (un modèle d'apprentissage automatique) pour deviner à leur place.

Ils ont utilisé une technique spéciale appelée Apprentissage PU (Apprentissage Positif-Non étiqueté).

L'analogie : Imaginez que vous essayez d'enseigner à un chien à trouver un type spécifique de balle. Vous avez quelques balles que vous savez être du bon type (les exemples Positifs). Mais vous avez un énorme tas de balles mélangées où vous ne savez pas lesquelles sont du bon type et lesquelles sont mauvaises (le tas Non étiqueté). Vous ne pouvez pas simplement dire « tout le reste est une mauvaise balle » car certaines d'entre elles pourraient en fait être du bon type, vous ne les avez simplement pas encore vérifiées.
Comment cela a fonctionné : Les chercheurs ont nourri leur modèle avec les « échecs sans rapport connus » et le « tas inconnu ». Le modèle a appris à repérer des motifs suggérant qu'un échec est probablement sans rapport, même sans étiquette claire.

À quel point l'assistant était-il bon ?

Le modèle a été testé sur les mêmes 7 projets.

Il était très bon en précision (quand il disait « Ce n'est pas de votre faute », il avait généralement raison, environ 70 % à 88 % du temps).
Il était bon en rappel (il a trouvé la plupart des échecs sans rapport, bien qu'il en ait manqué certains).
Il a nettement surpassé le hasard ou des règles simples.

Les « indices » utilisés par le modèle

Les chercheurs ont identifié trois principaux indices qui ont aidé le modèle à décider si un échec était sans rapport :

L'écart de temps (Latence CI) : Si un développeur a poussé du code et attendu longtemps avant de déclencher la construction, il est plus probable que quelqu'un d'autre ait cassé la cuisine entre-temps.
L'erreur « Déjà vu » : Si le message d'erreur ressemble exactement à un message qui s'est produit récemment, il s'agit probablement d'une répétition d'un ancien problème, et non d'un nouveau causé par le chef actuel.
Le bavardage : S'il y a beaucoup de commentaires sur le problème avant que l'échec ne se produise, cela suggère que le problème est complexe et implique probablement le travail d'autres personnes, et non seulement le push actuel.

La conclusion

L'article conclut qu'en utilisant cet « Assistant intelligent », les développeurs peuvent obtenir un indice rapide : « Il y a de fortes chances que cet échec ne soit pas de votre faute. »

Cela ne signifie pas qu'ils peuvent ignorer le problème, mais cela leur dit : « Ne passez pas 4 heures à vérifier votre propre code. Vérifiez peut-être le four ou demandez à l'autre chef. » Cela les aide à arrêter de perdre du temps sur de fausses alertes et à reprendre la cuisine (le codage) plus rapidement.

Note importante : L'article se concentre entièrement sur l'identification de ces échecs dans les projets logiciels. Il ne prétend pas que cette méthode fonctionne pour le diagnostic médical, le trading financier ou tout autre domaine en dehors du développement logiciel. C'est strictement un outil pour les équipes logicielles afin de gérer leur propre chaos de « cuisine ».

Résumé technique : Cette erreur de construction est-elle liée à mon correctif ? Une étude empirique des erreurs de construction non liées dans l'intégration continue

1. Énoncé du problème

Dans les environnements d'intégration continue (IC), plusieurs développeurs poussent souvent du code simultanément. Cette concurrence peut entraîner des erreurs de construction non liées : des échecs de construction légitimes qui surviennent durant le processus d'IC mais qui ne sont pas causés par la poussée de code actuelle. Contrairement aux tests instables (qui sont non déterministes), ces échecs sont réels mais découlent de facteurs tels que des ruptures en cascade provenant de poussées précédentes, des problèmes de configuration, des dépendances externes ou une instabilité de l'environnement.

Le problème central est que les développeurs doivent consacrer un temps considérable à l'investigation de ces échecs pour déterminer s'ils en sont responsables. Les données empiriques des auteurs révèlent que les développeurs investissent un temps médian de 4 heures pour confirmer si un échec est sans rapport avec leurs modifications. Ce « temps mal dépensé » crée une charge, pouvant entraîner une « fatigue des notifications » et une réduction de l'adhésion aux meilleures pratiques d'IC si les développeurs perçoivent les constructions comme échouant constamment en raison de facteurs hors de leur contrôle.

2. Méthodologie

L'étude adopte une approche mixte impliquant l'exploration de données, une analyse qualitative et un apprentissage semi-supervisé à travers sept projets de la Fondation Apache Software (ASF) (AMBARI, HADOOP, HBASE, HDDS, HDFS, HIVE, YARN).

2.1 Collecte de données et étiquetage heuristique

Jeu de données : Les auteurs ont extrait 77 354 échecs de construction IC à partir de rapports de problèmes JIRA.
Étiquetage basé sur des heuristiques (HL) : Pour identifier les échecs non liés potentiels, ils ont développé une heuristique basée sur des mots-clés. Ils ont recherché des termes spécifiques dans les commentaires des développeurs suivant un échec de construction (par exemple, « sans rapport », « non pertinent », « hors sujet », « non connecté »).
Ensemble initial : Ce processus a identifié 10 316 échecs de construction potentiellement non liés.
Curration de l'échantillon : À partir de cet ensemble, un échantillon statistiquement représentatif de 371 échecs véritablement non liés a été curé manuellement (niveau de confiance de 95 %, intervalle de confiance de 5 %) grâce à un processus rigoureux d'analyse documentaire impliquant plusieurs codeurs.

2.2 Analyse documentaire (Qualitative)

Les auteurs ont effectué une analyse thématique des 371 échecs curés pour comprendre pourquoi les développeurs les jugeaient sans rapport. Cela impliquait :

De traiter les journaux d'IC et les commentaires des développeurs comme des documents numériques.
Un codage inductif pour générer des thèmes.
Des vérifications de fiabilité inter-évaluateurs (scores de Kappa de Cohen de 0,76 à 0,77).

2.3 Ingénierie des caractéristiques

Sur la base des résultats qualitatifs, les auteurs ont extrait 33 caractéristiques à partir de trois dimensions :

Niveau du rapport de problème : Priorité, problèmes parallèles, liens inter-projets, statut de duplication, etc.
Niveau du commentaire : Nombre de commentaires précédents, messages d'erreur partagés avec des échecs antérieurs, nombre d'échecs similaires.
Niveau de la poussée : Latence IC (délai entre la soumission du correctif et le déclenchement de la construction), présence de correctifs de code/config, lignes ajoutées/modifiées/supprimées dans les fichiers source et de configuration.

Prétraitement : Les caractéristiques colinéaires ont été supprimées en utilisant la corrélation de rang de Spearman ( $|\rho| \ge 0,7$ ) et une analyse de redondance ( $R^2 > 0,9$ ) par projet.

2.4 Modélisation : Apprentissage Positif-Non-Étiqueté (PU)

Reconnaissant que le jeu de données est déséquilibré et que les instances « négatives » (échecs liés à la poussée) ne peuvent pas être étiquetées de manière fiable (car les développeurs n'indiquent pas explicitement qu'un échec est lié), les auteurs ont adopté un cadre d'apprentissage Positif-Non-Étiqueté (PU).

Classe Positive : Échecs non liés confirmés manuellement (371 échantillons, étendus à 700 pour l'entraînement).
Classe Non-Étiquetée : Tous les autres échecs de construction (contenant potentiellement à la fois des échecs liés et non liés).
Algorithmes : Deux variantes du classifieur Elkan & Noto ont été implémentées :
1. Elkan & Noto classique : Suppose que les données non étiquetées sont un mélange de positifs et de négatifs.
2. Elkan & Noto pondéré : Attribue des poids aux exemples non étiquetés pour tenir compte de la possibilité qu'ils contiennent des instances positives.
Hypothèse : L'étude valide l'hypothèse SCAR (Sélectionné Complètement au Hasard), garantissant que les instances positives étiquetées constituent un échantillon représentatif de toutes les instances positives.
Évaluation : Les modèles ont été évalués à l'aide d'une validation croisée à 10 plis et d'une stratégie de validation croisée inter-projets « leave-one-project-out ». Les métriques comprenaient la Précision, le Rappel, le score F1 et l'AUC.

3. Contributions clés

3.1 Caractérisation empirique

Coût temporel : Quantification du temps médian que les développeurs consacrent à la vérification des échecs non liés à 4 heures.
Causes racines : Identification de sept thèmes expliquant pourquoi les échecs sont jugés sans rapport :
1. Tests non liés (20 %) : Échecs dans des classes de tests sans rapport avec la poussée actuelle.
2. Non spécifié par le développeur (34,86 %) : Les développeurs indiquent « sans rapport » sans contexte.
3. Interférence externe (19,73 %) : Problèmes avec des bibliothèques ou des dépendances tierces.
4. Non reproductible (17,03 %) : Problèmes d'infrastructure transitoires (réseau, disque, délais d'attente).
5. Commits concurrents, problèmes de configuration et impact de l'environnement.

3.2 Modélisation prédictive

Développement de la première approche semi-supervisée pour prédire automatiquement les échecs de construction non liés.
Démonstration que les modèles Elkan & Noto pondérés surpassent systématiquement les lignes de base (Aléatoire, Positif Constant et correspondance heuristique des messages d'erreur).
Performance :
- AUC : Variant de 0,63 à 0,97 à travers les projets.
- Précision : Variant de 0,70 à 0,88.
- Rappel : Variant de 0,30 à 1,00.
- Score F1 : Variant de 0,44 à 0,91.
Généralisation : Les modèles ont maintenu des performances robustes dans la validation inter-projets, la variante pondérée montrant des améliorations significatives de la précision (gains de 13 à 24 %) par rapport à la variante classique.

3.3 Importance des caractéristiques

L'analyse d'importance des caractéristiques par permutation a révélé les indicateurs les plus influents pour les échecs non liés :

Latence IC : Le temps entre la soumission du correctif et la poussée déclenchant la construction. Une latence plus longue augmente la probabilité d'échecs non liés.
Messages d'erreur similaires : Si l'échec actuel partage un message d'erreur avec des échecs récents (indiquant des ruptures en cascade).
Nombre de commentaires précédents : Le volume de discussion précédant l'échec, qui peut indiquer des contextes complexes à multiples problèmes.

4. Signification et revendications

L'article revendique que sa contribution principale est de fournir un cadre semi-supervisé pour aider les développeurs à trier les échecs de construction. En prédisant la probabilité qu'un échec soit sans rapport avec la poussée actuelle, l'outil vise à :

Réduire l'effort des développeurs : Permettre aux développeurs de sauter l'investigation des changements de code lorsqu'un échec est probablement sans rapport, en se concentrant plutôt sur l'infrastructure ou sur le relancement de la construction.
Améliorer la prise de décision : Aider les équipes à décider s'il faut procéder à la fusion d'une contribution malgré un échec de construction.
Identifier des problèmes systémiques : Des prédictions répétées d'échecs non liés peuvent signaler des mauvaises configurations, des problèmes de réseau d'infrastructure ou des problèmes de dépendance nécessitant une surveillance systématique.

Les auteurs déclarent explicitement que leur objectif n'est pas d'atteindre une généralisation parfaite dans tous les domaines logiciels immédiatement, mais de démontrer la faisabilité de cette approche pour identifier les échecs non liés au sein d'écosystèmes d'IC matures. Ils soulignent que leur travail complète les recherches existantes sur les tests instables et la prédiction générale des résultats de construction en ciblant une classe spécifique, souvent négligée, d'échecs qui confondent les développeurs dans des environnements de développement concurrents.