Concurrerende patches in automatisch programmaherstel met Repairnator

Repairnator is een bot. Het controleert voortdurend softwarefouten die zijn ontdekt tijdens de continue integratie van open-source software en probeert deze automatisch op te lossen. Als het lukt om een ​​geldige patch te synthetiseren, stelt Repairnator de patch voor aan de menselijke ontwikkelaars, vermomd onder een valse menselijke identiteit. Tot op heden heeft Repairnator 5 patches kunnen produceren die door de menselijke ontwikkelaars zijn geaccepteerd en permanent in de codebasis zijn samengevoegd. Dit is een mijlpaal voor het concurrentievermogen van de mens op het gebied van software-engineeringonderzoek naar automatisch programmaherstel. In dit bericht vertellen we het verhaal over dit onderzoek aan het KTH Royal Institute of Technology, Inria, de Universiteit van Lille en de Universiteit van Valenciennes.

Programmaherstelonderzoek streeft het idee na dat algoritmen mensen kunnen vervangen om softwarefouten op te lossen [4]. Een bugfix is ​​een patch die broncode invoegt, verwijdert of wijzigt. In de volgende patch heeft de ontwikkelaar bijvoorbeeld de toestand van de instructie if gewijzigd:

- als (x <10)
+ if (x <= 10)
foo ();

Een programmaherstelbot is een kunstmatige agent die probeert broncodepatches te synthetiseren. Het analyseert bugs en produceert patches, op dezelfde manier als menselijke ontwikkelaars die betrokken zijn bij software-onderhoudsactiviteiten. Dit idee van een programma-reparatiebot is storend, omdat mensen tegenwoordig verantwoordelijk zijn voor het oplossen van bugs. Met andere woorden, we hebben het over een bot die bedoeld is om menselijke ontwikkelaars (gedeeltelijk) te vervangen voor vervelende taken.

Wanneer een bot een taak probeert te bereiken die meestal door mensen wordt gedaan, staat deze bekend als een competitieve taak voor mensen [1]. Uit de empirische evaluaties van programmaherstelonderzoek [3] blijkt dat de huidige programmaherstelsystemen in staat zijn om patches voor echte bugs in echte programma's te synthetiseren. Al die patches zijn echter gesynthetiseerd voor eerdere bugs, voor bugs die in het verleden, meestal jaren geleden, door menselijke ontwikkelaars zijn opgelost. Hoewel dit de technische haalbaarheid van programmaherstel aangeeft, bewijst dit niet dat programmaherstel menselijk concurrerend is.

Human-concurrentievermogen

Om aan te tonen dat programmaherstel concurrerend is voor mensen, moet een programmaherstelbot eerst een patch van hoge kwaliteit vinden voordat een mens dat doet. In deze context kan een patch als concurrerend voor de mens worden beschouwd als deze voldoet aan de twee voorwaarden voor tijdigheid en kwaliteit. Tijdigheid verwijst naar het feit dat het systeem een ​​patch moet vinden voor de menselijke ontwikkelaar. Met andere woorden, het prototypesysteem moet patches produceren in de orde van grootte van minuten, niet dagen. Ook moet de patch die door de bot wordt gegenereerd, correct genoeg zijn, van vergelijkbare kwaliteit - correct en leesbaar - in vergelijking met een patch die door een mens is geschreven. Merk op dat er patches zijn die er vanuit het oogpunt van de bot correct uitzien, maar die onjuist zijn (dit staat in de literatuur bekend als overfitting-patches [6, 3]). Die patches zijn aantoonbaar niet menselijk-competitief, omdat mensen ze nooit in hun codebasis zouden accepteren.

Dientengevolge, wil een patch concurrerend zijn voor de mens 1) de bot moet de patch sneller synthetiseren dan de menselijke ontwikkelaar 2) de patch moet door de menselijke ontwikkelaar goed genoeg worden beoordeeld en permanent worden samengevoegd in de codebasis.

Er is nog een aspect dat moet worden overwogen. Er is aangetoond dat menselijke ingenieurs bijdragen van bots niet zo gemakkelijk accepteren als bijdragen van andere mensen, ook al zijn ze strikt identiek [5]. De reden is dat mensen de neiging hebben a priori vooringenomenheid te hebben tegen machines en toleranter zijn voor fouten als de bijdrage van een menselijke peer komt. In de context van programmaherstel betekent dit dat ontwikkelaars de lat hoger kunnen leggen voor de kwaliteit van de patch, als ze weten dat de patch van een bot komt. Dit zou onze zoektocht naar menselijk concurrentievermogen in de context van programmaherstel belemmeren.

Om dit probleem op te lossen, hebben we vroeg in het project besloten dat alle Repairnator-patches zouden worden voorgesteld onder een valse menselijke identiteit. We hebben een GitHub-gebruiker gemaakt, Luc Esape genaamd, die wordt gepresenteerd als software-engineer in ons onderzoekslaboratorium. Luc heeft een profielfoto en ziet eruit als een junior-ontwikkelaar die graag open-sourcebijdragen levert op GitHub. Stel je nu Repairnator voor, vermomd als Luc Esape een patch voorstelt: de ontwikkelaar die het beoordeelt, denkt dat ze een menselijke bijdrage beoordeelt. Deze camouflage is nodig om onze wetenschappelijke hypothese van menselijk concurrentievermogen te testen. Nu, omwille van de ethiek, is de echte identiteit van Luc onthuld op elk van zijn pull-aanvragen.

Automatische reparatie en continue integratie

Continue integratie, ook wel CI genoemd, is het idee dat een server de code compileert en alle tests uitvoert voor elke commit in het versiebeheersysteem van een softwareproject (bijv. Git). In CI parlance is er een build voor elke commit. Een build bevat de informatie over de gebruikte momentopname van de broncode (bijvoorbeeld een verwijzing naar een Git-commit), het resultaat van compilatie en testuitvoering (bijvoorbeeld mislukking of succes) en een uitvoeringslogboek. Er wordt gezegd dat een build mislukt als compilatie mislukt of ten minste één testcase mislukt. Er is aangetoond dat ongeveer een op de 4 builds mislukt en dat de meest voorkomende oorzaak voor build-fouten een testfout is [8].

Het belangrijkste idee van Repairnator is om automatisch patches te genereren die fouten bij het bouwen repareren en deze vervolgens aan menselijke ontwikkelaars te laten zien, om uiteindelijk te zien of die menselijke ontwikkelaars ze als geldige bijdragen aan de codebasis zouden accepteren. Als dit gebeurt, zou dat een bewijs zijn van het concurrentievermogen van de mens bij programmaherstel.

Deze installatie - automatisch repareren van build-fouten die plaatsvinden bij continue integratie - is om de volgende redenen bijzonder geschikt en actueel. Ten eerste voldoen build-fouten aan de kernprobleemverklaring van op test-suite gebaseerde programmaherstel [4], waarbij bugs worden gespecificeerd als falende test-cases en die falende test-cases worden gebruikt om de geautomatiseerde synthese van een patch aan te sturen [4]. Ten tweede maakt het het mogelijk om bots en mensen op een eerlijke basis te vergelijken: wanneer een falende test wordt ontdekt op de continue integratieserver, worden de menselijke ontwikkelaar en de bot op hetzelfde moment op de hoogte gebracht. Deze testfoutmelding is het startpunt van de competitie tussen mens en bot.

De focus van Repairnator op build-fouten is uniek, maar het past in het grote geheel van intelligente bots voor software [2]. Facebook heeft bijvoorbeeld een tool genaamd SapFix die bugs repareert die zijn gevonden bij geautomatiseerd testen. Ook gerelateerd, de DARPA Cyber ​​Grand Challenge botaanvallers en verdedigers proberen mens-concurrerend te zijn met betrekking tot beveiligingsexperts.

Repairnator in het kort

In 2017–2018 hebben we Repairnator ontworpen, geïmplementeerd en geëxploiteerd, een bot voor geautomatiseerde programmaherstel. Repairnator is gespecialiseerd in het repareren van fouten tijdens het bouwen tijdens continue integratie. Het controleert voortdurend duizenden commits die naar het GitHub-codehostingplatform worden gepusht en analyseert de bijbehorende builds. Elke minuut lanceert het nieuwe reparatiepogingen om bugs voor de menselijke ontwikkelaar op te lossen. Het is ontworpen om zo snel mogelijk te gaan omdat het deelneemt aan een race: als Repairnator een patch vindt voor de menselijke ontwikkelaar, is het concurrerend voor de mens.

Laten we nu een overzicht geven van hoe de Repairnator-bot werkt.

De primaire input van Repairnator zijn continue integratie builds, geactiveerd door commits van ontwikkelaars (bovenste deel van de figuur, (a) en (b)) op basis van GitHub-projecten (a). De output van Repairnator is tweevoudig: (1) het produceert automatisch patches voor het repareren van falende builds (g), indien aanwezig; (2) het verzamelt waardevolle gegevens voor toekomstig onderzoek naar programmaherstel (h) en (k). Repairnator bewaakt permanent alle continue activiteit van GitHub-projecten ©. De CI-builds worden gegeven als input voor een driestaps-pijplijn: (1) een eerste fase verzamelt en analyseert CI-buildlogboeken (e); (2) een tweede fase is gericht op het lokaal reproduceren van de build-fouten die zijn opgetreden op CI (f); (3) een derde fase voert verschillende prototypen voor programmaherstel uit het laatste academische onderzoek. Wanneer een patch wordt gevonden, voert een Repairnator-projectlid een snelle sanity check uit om te voorkomen dat kostbare tijd wordt verspild aan open-sourceontwikkelaars. (i) Als ze de patch niet-gedegenereerd vindt, stelt ze hem voor aan de oorspronkelijke ontwikkelaars van het project als een pull-request op GitHub (j). De ontwikkelaars volgen dan hun gebruikelijke proces van code-review en samenvoegen.

Repairnator moet werken in een bepaald software-ecosysteem. Vanwege onze expertise met Java in eerdere onderzoeksprojecten, is de prototype-implementatie van Repairnator gericht op het repareren van software geschreven in de Java-programmeertaal, gebouwd met de Maven toolchain, in open-sourceprojecten gehost op GitHub, die gebruikmaken van het Travis CI-platform voor continue integratie .

Expeditieprestaties

We werken sinds januari 2017 in Repairnator, in drie verschillende fasen. Gedurende een maand, in januari 2017, hebben we een pilot-experiment uitgevoerd met een eerste versie van het prototype. Van 1 februari 2017 tot 31 december 2017 hebben we Repairnator uitgevoerd met een vaste lijst van 14.188 projecten, we noemen het "Expeditie # 1". Van 1 januari 2018 tot 30 juni 2018 heeft Repairnator de Travis CI-buildstream in realtime gevolgd, we noemen het "Expeditie # 2"

Het hoofddoel van het pilot-experiment was om ons ontwerp en onze eerste implementatie te valideren. We hebben geconstateerd dat ons prototype in staat is om ongeveer 30 reparatiepogingen per dag uit te voeren, gezien onze computerbronnen. Wat nog belangrijker is, dit pilot-experiment bevestigde onze technologische kernaannames: een aanzienlijk deel van de populaire open-sourceprojecten gebruiken Travis en de meerderheid van hen gebruikt Maven als build-technologie. Dit betekende dat we een eerlijke kans zouden hebben om ons doel te bereiken om in die context een mens-competitieve patch te synthetiseren.

Tijdens Expeditie # 1, waarvan de resultaten in detail worden gepresenteerd in [7], heeft Repairnator 11.523 builds met testfouten geanalyseerd. Voor 3.551 van hen (30,82%) kon Repairnator de testfout lokaal reproduceren. Van 3.551 reparatiepogingen vond Repairnator 15 patches die de CI-build konden passeren. Uit onze patch-analyse bleek echter dat geen van die patches concurrerend was voor de mens omdat ze te laat kwamen (Repairnator produceerde een patch na de menselijke ontwikkelaar) of van lage kwaliteit (ze maakten de build toevallig toevallig).

Expeditie # 2 is de succesvolle. Het heeft aangetoond dat programmahersteltechnologie de grens van menselijk concurrentievermogen heeft overschreden. Repairnator heeft 5 patches geproduceerd die voldoen aan de hierboven gedefinieerde criteria voor menselijk concurrentievermogen: 1) de patches werden geproduceerd vóór de menselijke, 2) een menselijke ontwikkelaar accepteerde de patches als geldige bijdragen en de patches werden samengevoegd in de hoofdcodebasis.

Mens-competitieve bijdragen op Github, patches gesynthetiseerd door de Repairnator-robot en aanvaard door de menselijke ontwikkelaar:

  • 12 jan. 2018, aaime / geowebcache / pull / 1, "Bedankt voor de patch!"
  • 23 maart 2018, parkito / BasicDataCodeU […] / pull / 3 “samengevoegde commit 140a3e3 in parkito: ontwikkelen”
  • 5 april 2018, dkarv / jdcallgraph / pull / 2 “Bedankt!”
  • 3 mei 2018, eclipse / idem / pull / 151 "Cool, bedankt voor het doorlopen van het Eclipse-proces en voor de oplossing."
  • 25 juni 2018, donnelldebnam / CodeU […] / pull / 151 “Bedankt !!”

De eerste patch samengevoegd door ons programma reparatie bot werd aanvaard door een menselijke ontwikkelaar op 12 januari 2018. Hier is het verhaal: op 12 januari 2018 om 12:28 uur werd een build geactiveerd op project aaime / geowebcache11 1 https: // travis -ci.org/GeoWebCache/geowebcache/builds/328076497. De build is mislukt na 2 minuten uitvoering, omdat twee testgevallen fout waren. Veertig minuten later, op 12 januari 2018 om 13:08 uur, ontdekte Repairnator de mislukte build tijdens de reguliere monitoring en begon het de beschikbare programmaherstelsystemen uit te voeren die in Repairnator waren geconfigureerd. Tien minuten later, om 13:18 uur, vond het een patch.

Op 12 januari 2018, om 13:35 uur, nam een ​​Repairnator-teamlid de patch die door Repairnator was gegenereerd en valideerde de opening van het bijbehorende pull-verzoek op GitHub. Op 12 januari 2018, om 14.10 uur, accepteerde de ontwikkelaar de patch en voegde deze samen met een opmerking: “Raar, ik dacht dat ik dit al had opgelost ... misschien deed ik dat op een andere plaats. Bedankt voor de patch! ”. Dat was de eerste patch geproduceerd door Repairnator en geaccepteerd als een geldige bijdrage van een menselijke ontwikkelaar, definitief samengevoegd in de codebasis. Met andere woorden, Repairnator was voor het eerst menselijk concurrerend.

Na nog 6 maanden bedrijf heeft Repairnator 5 patches samengevoegd door menselijke ontwikkelaars, die hierboven worden vermeld.

Over het algemeen heeft het Repairnator-project zijn missie volbracht. Het heeft aangetoond dat programmaherstel als concurrerend voor de mens kan worden beschouwd: Repairnator heeft pleisters gevonden 1) vóór de mens, 2) die door mensen zelf als van goede kwaliteit werden beschouwd.

De toekomst

Het Repairnator-project heeft niet alleen aangetoond dat programmaherstel concurrerend is voor mensen, maar biedt ook een schat aan informatie over bugs en voortdurende integratie en over de huidige tekortkomingen van onderzoek naar programmaherstel, gepresenteerd in [7].

Laten we in het bijzonder stilstaan ​​bij één punt, de kwestie van intellectuele eigendom. Op 3 mei 2018 produceerde Repairnator een goede patch voor het eclipse / idem van het GitHub-project. Kort nadat de patch was voorgesteld, vroeg een van de ontwikkelaars: "We kunnen alleen pull-aanvragen accepteren die afkomstig zijn van gebruikers die de Licentieovereenkomst voor de Eclipse Foundation-bijdrager hebben ondertekend." We waren verbaasd omdat een bot fysiek of moreel geen licentieovereenkomst kan ondertekenen en daar waarschijnlijk geen recht op heeft. Wie bezit het intellectuele eigendom en de verantwoordelijkheid van een botbijdrage: de robotoperator, de botimplementator of de ontwerper van het reparatie-algoritme? Dit is een van de interessante vragen van het Repairnator-project.

Wij zijn van mening dat Repairnator een bepaalde toekomst van software-ontwikkeling voorspelt, waar bots en mensen soepel zullen samenwerken en zelfs samenwerken aan software-artefacten.

Wil je lid worden van de Repairnator-community? Stuur een e-mail naar repairnator.subscribe@4open.science om regelmatig nieuws over Repairnator te ontvangen!

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

In de media:

  • Het mysterieuze leven van Luc Esape, bug fixer extraordinaire. Zijn grote geheim? Hij is niet menselijk (Thomas Claburn, The Register)

Referenties

  • [1] J. R. Koza (2010) Mens-competitieve resultaten geproduceerd door genetische programmering. Genetische programmering en evolueerbare machines 11 (3–4), pp. 251–284. Geciteerd door: .
  • [2] C. Lebeuf, M. D. Storey en A. Zagalsky (2018) Softwarebots. IEEE Software 35, pp. 18–23. Geciteerd door: Automatische reparatie en continue integratie.
  • [3] M. Martinez, T. Durieux, R. Sommerard, J. Xuan en M. Monperrus (2016) Automatische reparatie van echte bugs in Java: een grootschalig experiment met de Defects4j-gegevensset. Empirical Software Engineering, pp. 1-29. Geciteerd door: Menselijk concurrentievermogen,.
  • [4] M. Monperrus (2017) Automatische softwarereparatie: een bibliografie. ACM Computing Surveys. Geciteerd door: Automatische reparatie en continue integratie,.
  • [5] A. Murgia, D. Janssens, S. Demeyer en B. Vasilescu (2016) Onder de machines: interactie tussen mens en bot op sociale vraag- en antwoordwebsites. In Proceedings of the CHI Conference 2016 Extended Abstracts on Human Factors in Computing Systems, pp. 1272–1279. Geciteerd door: Human-competitiveness.
  • [6] E. K. Smith, E. T. Barr, C. Le Goues en Y. Brun (2015) Is de remedie erger dan de ziekte? overfitting in geautomatiseerde programmaherstel. In Proceedings of the 10th Joint Meeting on Foundations of Software Engineering 2015, pp. 532–543. Externe links: document Geciteerd door: Menselijk concurrentievermogen.
  • [7] S. Urli, Z. Yu, L. Seinturier en M. Monperrus (2018) Hoe een programmaherstelbot te ontwerpen? Inzichten uit het Repairnator-project. In ICSE 2018–40e International Conference on Software Engineering, Track Software Engineering in Practice, External Links: Link Cited by: Expedition Achievements, The Future.
  • [8] C. Vassallo, G. Schermann, F. Zampetti, D. Romano, P. Leitner, A. Zaidman, M. Di Penta en S. Panichella (2017) A Tale of CI Build Failures: An Open-source and een perspectief van een financiële organisatie. In International Conference on Software Maintenance and Evolution, geciteerd door: Automatic Repair and Continuous Integration.