Correctifs humains-compétitifs dans la réparation automatique de programmes avec Repairnator

Repairnator est un bot. Il surveille en permanence les bogues logiciels découverts lors de l'intégration continue de logiciels à code source ouvert et tente de les résoudre automatiquement. S'il réussit à synthétiser un correctif valide, Repairnator le propose aux développeurs humains, déguisés sous une fausse identité humaine. À ce jour, Repairnator a été en mesure de produire 5 correctifs acceptés par les développeurs humains et intégrés de manière permanente dans la base de code. C’est une étape importante pour la compétitivité humaine dans la recherche en génie logiciel sur la réparation automatique de programmes. Dans cet article, nous racontons l’histoire de ces recherches menées à l’Institut royal de technologie du KTH, à Inria, à l’Université de Lille et à l’Université de Valenciennes.

La recherche sur les réparations de programme poursuit l'idée que les algorithmes peuvent remplacer les humains pour corriger les bogues logiciels [4]. Un correctif de bogue est un correctif qui insère, supprime ou modifie le code source. Par exemple, dans le correctif suivant, le développeur a modifié la condition de l'instruction if:

- si (x <10)
+ si (x <= 10)
foo ();

Un robot de réparation de programme est un agent artificiel qui tente de synthétiser des correctifs de code source. Il analyse les bogues et produit des correctifs, de la même manière que les développeurs humains impliqués dans les activités de maintenance logicielle. Cette idée d'un robot de réparation de programme est perturbatrice, car aujourd'hui, les humains sont responsables de la correction des bogues. En d'autres termes, nous parlons d'un bot destiné à remplacer (partiellement) les développeurs humains pour des tâches fastidieuses.

Lorsqu'un bot essaie d'accomplir une tâche habituellement effectuée par des humains, il s'agit d'une tâche concurrentielle [1]. Les évaluations empiriques de la recherche sur la réparation de programme [3] montrent que les systèmes actuels de réparation de programme sont capables de synthétiser des correctifs pour de vrais bugs dans des programmes réels. Cependant, tous ces correctifs ont été synthétisés pour les bogues passés, pour ceux corrigés par les développeurs humains dans le passé, généralement il y a plusieurs années. Bien que cela indique la faisabilité technique de la réparation du programme, cela ne montre pas que la réparation du programme est compétitive sur le plan humain.

Compétitivité humaine

Pour démontrer que la réparation d'un programme est compétitive sur le plan humain, un robot de réparation de programme doit trouver un correctif de haute qualité avant qu'un humain ne le fasse. Dans ce contexte, un patch peut être considéré comme concurrentiel sur le plan humain s'il remplit les deux conditions de rapidité et de qualité. La rapidité d'exécution fait référence au fait que le système doit trouver un correctif avant le développeur humain. En d’autres termes, le système prototype doit produire des patchs dans l’ordre de grandeur des minutes, et non des jours. De plus, le correctif généré par le bot doit être suffisamment correct, de qualité similaire - correct et lisible - comparé à un correctif écrit par un humain. Notez que certains correctifs semblent corrects du point de vue du bot, mais qu’ils sont incorrects (il s’agit de correctifs excessifs dans la littérature [6, 3]). Ces correctifs ne sont sans doute pas compétitifs, car les humains ne les accepteraient jamais dans leur code.

Par conséquent, pour qu'un correctif soit compétitif sur le plan humain 1), le bot doit synthétiser le correctif plus rapidement que le développeur humain. 2) le correctif doit être jugé suffisamment bon par le développeur humain et intégré de manière permanente dans la base de code.

Il y a un autre aspect à considérer. Il a été démontré que les ingénieurs humains n'acceptent pas les contributions de robots aussi facilement que les contributions d'autres humains, même si elles sont strictement identiques [5]. La raison en est que les humains ont tendance à avoir des préjugés à priori contre les machines et qu’ils sont plus tolérants aux erreurs si la contribution provient d’un pair humain. Dans le contexte de la réparation du programme, cela signifie que les développeurs peuvent placer la barre plus haut pour la qualité du correctif s’ils savent que le correctif provient d’un bot. Cela entraverait notre recherche d'une preuve de compétitivité humaine dans le contexte de la réparation du programme.

Pour surmonter ce problème, nous avons décidé au début du projet que tous les correctifs Repairnator seraient proposés sous une fausse identité humaine. Nous avons créé un utilisateur GitHub, appelé Luc Esape, qui est présenté en tant qu’ingénieur logiciel dans notre laboratoire de recherche. Luc a une photo de profil et ressemble à un développeur junior, désireux de faire des contributions open-source sur GitHub. Imaginez maintenant Repairnator, déguisé en Luc Esape qui propose un correctif: le développeur qui l’a examiné pense qu’il examine une contribution humaine. Ce camouflage est nécessaire pour tester notre hypothèse scientifique de compétitivité humaine. Maintenant, pour des raisons d'éthique, la véritable identité de Luc a été révélée sur chacune de ses demandes d'attraction.

Réparation automatique et intégration continue

L'intégration continue, ou CI, est l'idée qu'un serveur compile le code et exécute tous les tests pour chaque validation effectuée dans le système de contrôle de version d'un projet logiciel (par exemple, Git). Dans le langage de CI, il existe une construction pour chaque commit. Une construction contient les informations sur l’instantané de code source utilisé (par exemple, une référence à une validation Git), le résultat de la compilation et de l’exécution du test (par exemple, échec ou succès) et un journal de suivi de l’exécution. On dit qu'une construction échoue si la compilation échoue ou si au moins un cas de test échoue. Il a été démontré qu'environ une génération sur 4 échouait et que la cause la plus courante d'échec de génération était un échec de test [8].

L'idée principale de Repairnator est de générer automatiquement des correctifs qui réparent les échecs de construction, puis de les montrer aux développeurs humains, afin de voir si ces développeurs les accepteraient comme des contributions valables à la base de code. Si cela se produit, ce sera la preuve de la compétitivité humaine dans la réparation du programme.

Cette configuration, qui répare automatiquement les échecs de construction lors d’une intégration continue, est particulièrement appropriée et opportune pour les raisons suivantes. Tout d'abord, les échecs de construction répondent à l'énoncé du problème principal de la réparation de programme basée sur la suite de tests [4], dans lequel les bogues sont spécifiés comme cas de test défaillants, et ces tests de test défaillants sont utilisés pour piloter la synthèse automatisée d'un correctif [4]. Deuxièmement, cela permet de comparer équitablement les robots et les humains: lorsqu'un test ayant échoué est découvert sur le serveur d'intégration continue, le développeur humain et le bot en sont informés au même moment. Cette notification d'échec de test est le point de départ de la compétition homme contre bot.

L’attention de Repairnator sur les échecs de construction est unique, mais elle s’intègre dans l’ensemble des robots intelligents pour logiciels [2]. Par exemple, Facebook dispose d'un outil appelé SapFix qui répare les bogues détectés lors des tests automatisés. Également lié, les attaquants et les défenseurs du DARPA Cyber ​​Grand Challenge tentent d’être compétitifs face aux experts en sécurité.

Repairnator en quelques mots

En 2017-2018, nous avons conçu, mis en œuvre et exploité Repairnator, un bot pour la réparation automatisée de programmes. Repairnator est spécialisé dans la réparation des échecs de construction survenant lors de l'intégration continue. Il surveille en permanence des milliers de commits envoyés à la plate-forme d'hébergement de code GitHub et analyse les versions correspondantes. Chaque minute, il lance de nouvelles tentatives de réparation afin de corriger les bogues avant le développeur humain. Il est conçu pour aller aussi vite que possible car il participe à une course: si Repairnator trouve un correctif avant le développeur humain, il est compétitif sur le plan humain.

Donnons maintenant un aperçu du fonctionnement du bot Repairnator.

Les entrées principales de Repairnator sont des versions d'intégration continue, déclenchées par des validations effectuées par les développeurs (partie supérieure de la figure, (a) et (b)) sur la base de projets GitHub (a). Les sorties de Repairnator sont doubles: (1) il produit automatiquement des correctifs pour réparer les versions défaillantes (g), le cas échéant; (2) il collecte des données précieuses pour la recherche future sur la réparation du programme (h) et (k). Repairnator surveille en permanence toute l'activité continue des projets GitHub ©. Les constructions de CI sont données en entrée dans un pipeline en trois étapes: (1) une première étape consiste à collecter et à analyser les journaux de construction de CI (e); (2) une deuxième étape vise à reproduire localement les échecs de construction survenus dans CI (f); (3) une troisième étape consiste en différents prototypes de réparation de programmes issus des dernières recherches académiques. Lorsqu'un correctif est trouvé, un membre du projet Repairnator effectue une vérification rapide de l'intégrité, afin d'éviter de perdre un temps précieux aux développeurs open source. (i) Si elle trouve le correctif non dégénéré, elle le propose ensuite aux développeurs initiaux du projet sous forme de requête d'extraction sur GitHub (j). Les développeurs suivent ensuite leur processus habituel de révision de code et de fusion.

Repairnator doit fonctionner dans un écosystème logiciel donné. En raison de notre expertise de Java dans des projets de recherche antérieurs, Repairnator met en œuvre son prototype de réparation de logiciels écrits dans le langage de programmation Java, construit avec la chaîne d'outils Maven, dans des projets open source hébergés sur GitHub, qui utilisent la plate-forme d'intégration continue Travis CI. .

Réalisations de l'expédition

Nous exploitons Repairnator depuis janvier 2017, en trois phases différentes. Pendant un mois, en janvier 2017, nous avons effectué une expérience pilote avec une version initiale du prototype. Du 1er février 2017 au 31 décembre 2017, nous avons lancé Repairnator avec une liste fixe de 14 188 projets, baptisée «Expédition n ° 1». Du 1er janvier 2018 au 30 juin 2018, Repairnator a surveillé le flux de construction de Travis CI en temps réel, nous l'appelons «Expédition n ° 2».

L’expérience pilote avait pour objectif principal de valider notre conception et notre mise en œuvre initiale. Nous avons constaté que notre prototype pouvait effectuer environ 30 tentatives de réparation par jour, compte tenu de nos ressources informatiques. Plus important encore, cette expérience pilote a validé nos hypothèses technologiques fondamentales: une proportion importante des projets open source populaires utilisent Travis et la majorité d'entre eux utilisent Maven en tant que technologie de construction. Cela signifiait que nous aurions une bonne chance d'atteindre notre objectif de synthétiser un patch compétitif sur le plan humain dans ce contexte.

Lors de l'expédition n ° 1, dont les résultats sont présentés en détail dans [7], Repairnator a analysé 11 523 versions avec échecs de test. Pour 3551 d'entre eux (30,82%), Repairnator a été capable de reproduire localement l'échec du test. Sur 3 551 tentatives de réparation, Repairnator a trouvé 15 correctifs susceptibles de faire passer la construction de CI. Cependant, notre analyse de correctifs a révélé qu'aucun de ces correctifs n'était compétitif par rapport à l'homme car ils sont arrivés trop tard (Repairnator a produit un correctif après le développeur humain) ou étaient de qualité médiocre (ils ont coïncidé avec le succès de la construction).

L'expédition # 2 est celle qui a réussi. Il a montré que la technologie de réparation de programme a franchi la frontière de la compétitivité humaine. Repairnator a produit 5 correctifs qui répondent aux critères de compétitivité humaine définis ci-dessus: 1) les correctifs ont été produits avant les humains, 2) un développeur humain a accepté les correctifs en tant que contributions valides et les correctifs ont été fusionnés dans la base de code principale.

Contributions humaines sur Github, correctifs synthétisés par le robot Repairnator et acceptés par le développeur humain:

  • 12 janvier 2018, aaime / geowebcache / pull / 1, "Merci pour le patch!"
  • 23 mars 2018, parkito / BasicDataCodeU […] / pull / 3 “fusionner la validation 140a3e3 dans parkito: développer”
  • 5 avril 2018, dkarv / jdcallgraph / pull / 2 “Merci!”
  • 3 mai 2018, eclipse / ditto / pull / 151 «Cool, merci d'avoir suivi le processus Eclipse et pour le correctif.»
  • 25 juin 2018, donnelldebnam / CodeU […] / pull / 151 “Merci !!”

Le premier correctif fusionné par notre programme de réparation de programmes a été accepté par un développeur humain le 12 janvier 2018. Voici l'histoire: le 12 janvier 2018 à 12 h 28, une compilation a été déclenchée sur le projet aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. La génération a échoué après 2 minutes d'exécution, car deux cas de test étaient erronés. Quarante minutes plus tard, le 12 janvier 2018 à 13h08, Repairnator a détecté la construction défaillante au cours de sa surveillance régulière et a commencé à exécuter les systèmes de réparation de programme disponibles configurés dans Repairnator. Dix minutes plus tard, à 13h18, il a trouvé un patch.

Le 12 janvier 2018, à 13 h 35, un membre de l'équipe Repairnator a pris le correctif généré par Repairnator et a validé l'ouverture de la demande d'extraction correspondante sur GitHub. Le 12 janvier 2018, à 14 h 10, le développeur a accepté le correctif et l'a fusionné avec un commentaire: «Bizarre, je pensais avoir déjà résolu ce problème… peut-être que je l'avais déjà fait à un autre endroit. Merci pour le patch! ”. Ce fut le premier correctif produit par Repairnator et accepté comme une contribution valable par un développeur humain, définitivement intégré dans la base de code. En d'autres termes, Repairnator était compétitif pour la première fois.

Après 6 mois d'exploitation supplémentaire, Repairnator a fusionné 5 correctifs créés par des développeurs humains, répertoriés ci-dessus.

Dans l’ensemble, le projet Repairnator a rempli sa mission. Il a montré que la réparation du programme pouvait être considérée comme compétitive sur le plan humain: Repairnator a trouvé des correctifs 1) avant les humains, 2) considérés comme de bonne qualité par les humains eux-mêmes.

L'avenir

En plus de montrer que la réparation du programme est compétitive sur le plan humain, le projet Repairnator a fourni une mine d'informations sur les bugs et l'intégration continue, ainsi que sur les lacunes actuelles de la recherche sur la réparation de programme présentée dans [7].

Arrêtons-nous sur un point en particulier, la question de la propriété intellectuelle. Le 3 mai 2018, Repairnator a produit un bon patch pour le projet GitHub eclipse / ditto. Peu de temps après avoir proposé le correctif, l'un des développeurs a demandé: «Nous ne pouvons accepter que les demandes d'extraction provenant d'utilisateurs ayant signé le contrat de licence d'Eclipse Foundation Contributor.». Nous étions perplexes car un bot ne peut pas signer physiquement ou moralement un contrat de licence et n’a probablement pas le droit de le faire. À qui appartient la propriété intellectuelle et la responsabilité d'une contribution de bot: l'opérateur du robot, son implémenteur ou le concepteur de l'algorithme de réparation? C'est l'une des questions intéressantes soulevées par le projet Repairnator.

Nous pensons que Repairnator préfigure un certain avenir dans le développement de logiciels, où les robots et les humains vont collaborer sans heurts et même coopérer sur les artefacts logiciels.

Voulez-vous rejoindre la communauté Repairnator? Pour recevoir régulièrement des nouvelles de Repairnator, envoyez un courrier électronique à l'adresse repairnator.subscribe@4open.science!

- Martin Monperrus, Simon Urli, Thomas Durieux, Matias Martinez, Benoit Baudry et Lionel Seinturier

Dans les médias:

  • La vie mystérieuse de Luc Esape, extraordinaire correcteur de bugs. Son grand secret? Il n’est pas humain (Thomas Claburn, The Register)

Références

  • [1] J. R. Koza (2010), Résultats de la compétition entre les humains produits par la programmation génétique. Programmation génétique et machines évolutives 11 (3-4), p. 251–284. Cité par: .
  • [2] C. Lebeuf, M. D. Storey et A. Zagalsky (2018), bots logiciels. Logiciel IEEE 35, p. 18-23. Cité par: Réparation automatique et intégration continue.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan et M. Monperrus (2016). Réparation automatique de vrais bugs en Java: une expérience à grande échelle sur le jeu de données Défauts4j. Génie logiciel empirique, p. 1–29. Cité par: Compétitivité humaine,.
  • [4] M. Monperrus (2017), Réparation automatique de logiciels: une bibliographie. ACM Computing Surveys. Cité par: Réparation automatique et intégration continue,.
  • [5] A. Murgia, D. Janssens, S. Demeyer et B. Vasilescu (2016) Parmi les machines: Interaction homme-robot sur des sites Web de questions sociales. Dans Actes de la conférence 2016 de la Conférence CHI, résumés détaillés sur les facteurs humains dans les systèmes informatiques, p. 1272–1279. Cité par: Compétitivité humaine.
  • [6] E. K. Smith, E.T. Barr, C. Le Goues et Y. Brun (2015). Le remède est-il pire que la maladie? overfitting dans la réparation de programme automatisée. Dans Actes de la 10e réunion commune sur les fondements du génie logiciel de 2015, pp. 532-543. Liens externes: Document cité par: Compétitivité humaine.
  • [7] S. Urli, Z. Yu, L. Seinturier et M. Monperrus (2018) Comment concevoir un bot de réparation de programme? Aperçus du projet Repairnator. Dans ICSE 2018–40ème Conférence internationale sur le génie logiciel, le logiciel de suivi de piste en pratique, liens externes: Lien cité par: Expedition Accomplissements, l'avenir.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta et S. Panichella (2017). Un conte des échecs de construction de CI: une source ouverte et une perspective d'organisation financière. Conférence internationale sur l'évolution et la maintenance des logiciels, citée par: Réparation automatique et intégration continue.