DOCSEARCHbyAlgolia
Submit Docs

Repairnator Documentation

repository·master·Indexed 18 days ago

https://github.com/eclipse-repairnator/repairnator

An open-source platform hosted by the Eclipse Foundation for developing and deploying software bots on GitHub. It focuses on automated program repair (APR) tasks, such as fixing build failures and static warnings. The platform includes a pipeline for cloning, building, and repairing programs, as well as scanners like RTScanner and FastScanner for detecting failing builds. It also supports SOBO, an automatic feedback bot for Java programs, and integrates with MongoDB for storing build statuses, metrics, and repair data.

Tokens
22.6K
Snippets
62
Records
111
Agent score
63%

What's inside Repairnator

  1. Overview of Repairnator

    master
    Repairnator is an open-source platform hosted by the Eclipse Foundation designed for software bots on GitHub. It specifically focuses on automated program repair (APR) tasks, such as repairing build failures and addressing static warnings (e.g., via SoraldBot).

  2. Overview of Repairnator components

    master

    Repairnator is composed of several specialized modules that handle different stages of the software repair lifecycle:

    • repairnator-core: Contains shared elements used across the platform. It can also be used to generate Google Spreadsheets Credentials.
    • repairnator-pipeline: The core engine of Repairnator. It takes a build ID, performs compilation, testing, and repair, gathers data, and then pushes results to GitHub and MongoDB.
    • repairnator-realtime: A monitoring component that inspects Travis builds in real-time (typically every minute).
    • docker-images: Contains the content for the various Docker images produced for the platform.
    • scripts: A collection of scripts used to run and automate Repairnator processes.

  4. Understand the structure of Bears data

    master

    The Bears data repository contains information used to obtain bugs from GitHub repositories. The data is organized into project lists, scanned build pairs, and validated branches:

    • list-of-projects.txt: A text file containing the names of GitHub repositories used as sources for bugs.
    • scanned-builds/: Contains pairs of builds scanned from the projects listed in list-of-projects.txt. Each pair consists of a buggy build and its corresponding fixer build, intended to be reproduced to verify the bug/fix relationship.
    • branches/: Contains information regarding branches generated via the Bears collection process. This folder is subdivided into:
      • 1-reproduced-build-branches/: Lists of branches generated from successfully reproduced build pairs.
      • 2-validation-results/: Lists of branches from the previous step that were reproduced a second time for validation. Branches are annotated with either [OK] (successfully validated) or [FAILURE] (unsuccessfully validated).
      • 3-successfully-validated-branches/: Lists of branches that achieved an [OK] status during the validation phase.

  5. Understand the Repairnator Website Architecture

    master

    The Repairnator website is a decoupled system designed to display statistics derived from a MongoDB instance containing Repairnator data. It consists of two primary components:

    1. repairnator-mongo-rest-api: A backend service that provides a REST-like API interface to the underlying MongoDB database.
    2. repairnator-site: A frontend application that consumes the REST API to visualize and display the data.

    To deploy the full website experience, both the API and the site component must be operational and connected.

  6. How the Repairnator Scanner works

    master

    Scanners are daemons used to automate the detection of failing builds.

    • RTScanner: Constantly inspects Travis CI to catch newly failing builds and launch a pipeline for each.
    • FastScanner: An alternative implementation of the same concept.

    Scanners can be deployed in environments like Kubernetes.

  7. How the Repairnator GitHub App works

    master

    The app functions as a bridge between GitHub webhooks and the Repairnator pipeline via ActiveMQ:

    1. Webhook Listening: The server listens for GitHub events.
    2. Build Info Retrieval: For relevant events, the server requests build information from the Travis API.
    3. Queueing: For every failing Java build, the server pushes the buildId to a Repairnator ActiveMQ server.
    4. Repair Pipeline: The Repairnator-pipeline consumes the buildId from ActiveMQ, invokes repair tools to generate patches, and if successful, creates a pull request on GitHub.

  8. How Flacoco Scanner works

    master

    The Flacoco Scanner (used by Flacocobot) performs fault localization on pull requests. It operates in two modes based on the configuration of the FLACOCO_RESULTS_REPOSITORY environment variable:

    1. Review Comment Mode: If FLACOCO_RESULTS_REPOSITORY is NOT set, the scanner adds a review comment to the failing pull request if it finds suspicious lines within the PR's diff. It suggests the top 5 most suspicious lines by default.
    2. Repository Mode: If FLACOCO_RESULTS_REPOSITORY IS set to a GitHub repository slug, the scanner saves results as .MD files in that repository.
      • Files starting with diff_ contain suspicious lines found within the PR diff.
      • Other files contain the top 5 most suspicious lines found in the project generally.

    To specify which projects to scan, create a file containing one project slug per line (format: <user>/<repo-name>) and set the PROJECTS_TO_SCAN_FILE environment variable to its path.

  9. How the Repairnator Pipeline works

    master

    The pipeline is the core abstraction of Repairnator. It takes a Travis CI build ID as input and executes a sequence of steps: cloning the repository, building it, replicating the bug, and attempting repairs using various program repair tools. Finally, it can push the resulting branch or create a pull request.

    The pipeline can be used directly in Java or encapsulated within a Docker image to provide a sandboxed environment with all necessary dependencies.

  10. How to link data between different MongoDB collections

    master

    To join or link data across different Repairnator collections, you must use the correct identifiers. Avoid using the standard MongoDB UUID, as it is unique to each collection and cannot be used for cross-collection linking.

    Use the following strategy for linking:

    1. Build ID: This is the Travis ID of a specific build. While useful, be aware that the same Build ID might have been computed at different times.
    2. Run ID: This ID, when used in conjunction with the Build ID, guarantees the uniqueness of a specific computation.

    Best Practice: Always use both Build ID and Run ID together to ensure you are linking to the correct, unique computation instance.

  12. Save MongoDB backups on librepair

    master

    On the librepair machine, MongoDB backups are automatically performed every 24 hours via a cron job. Backups are stored in /mnt/backup/repairnator/db. The backup script is located at /root/backup-repairnator.sh and uses mongodump with the --gzip and --archive flags to create dated compressed archives.

    mongodump -u *** -p *** --db repairnator --gzip --archive=/mnt/backup/repairnator/db/repairnator_`date +"%y-%m-%d"`.gz