Imagine a software development world where humans and bots will interact together on the same code base. Bots would review code written by humans, and humans would review code synthesized by bots. Bots would help humans do mundane tasks such as formatting, and humans would focus on the hardest creative tasks (see some examples of already existing bots to improve your software development process) In my research group at KTH Royal Institute of Technology and Inria, we are contributing to this future, we are designing and prototyping the next generation of software development bots beyond chatbots.
The Repairnator project is a project to design, implement and operate a repair bot for continuous integration. This repair bot itself is called after the project: “Repairnator”. Repairnator constantly monitors test failures happening in continuous integration. When a test failure happens on CI, Repairnator gets the corresponding commit, runs the best-of-breed program repair tools, and finally suggests a patch to the developer as a pull request on Github. Repairnator aims to propose patches for bugs to open-source developers before they have themselves fixed those bugs. In other terms, Repairnator aims at being faster than humans to fix bugs, aims at being human-competitive.
The figure below gives an overview of how the Repairnator bot works. The primary input of Repairnator is continuous-integration builds, triggered by commits made by developers (top part of the figure, arrows (a) and (b)).
The Repairnator bot itself works as follows. Continuously, it monitors all continuous integration activity on Travis of open-source projects on Github (c). The CI builds are given as input to a pipeline that contains three stages: (1) a first stage, called CI Build Analysis, that collects and analyzes CI builds (d) from GitHub projects (a and b)(2) a second stage, called Bug Reproduction, that aims at reproducing the build failures that have happened on CI (3) a third stage, called Patch Synthesis, that uses the failure reproduction information to search for patches.
We don’t fully automate the creation of pull requests with the Repairnator patches, because the program repair tools are still prototypes. As shown in Figure 1, when a patch is found, the produced patches are first analyzed by a Repairnator team member (i): if she finds a patch correct, she then proposes it for the original developers of the project to fix the bug (j).
At the time of writing this post, Repairnator (the bot) has produced 4 patches that were merged by open-source lead developers (humans). In those 4 cases, Repairnator was faster than the human, it was human-competitive.
Do you like research? I’m looking for enthusiasts, PhD students and postdocs to work on Repairnator, contact us: martin.monperrus@csc.kth.se
Links:
- Paper: How to Design a Program Repair Bot? Insights from the Repairnator Project (), In ICSE 2018 – 40th International Conference on Software Engineering, Track Software Engineering in Practice (SEIP), 2018.
- Github: https://github.com/Spirals-Team/repairnator/
- Join us at the ICSE conference: June 1 2018, 12:00 in Gothenburg!