Skip to content
This repository was archived by the owner on Feb 20, 2023. It is now read-only.

Pull Request Process

Matt Butrovich edited this page Aug 22, 2018 · 13 revisions

Prerequisites

[TODO: Docs are lying until we get Jenkins set up.]
[TODO: Once benchmarks are running on Jenkins, describe the allowed performance regression level.]

Before Opening Your PR

Continuous Integration

We currently use Travis, Jenkins and Coveralls for our Continuous Integration.

  • Travis quickly checks the code for formatting, style and best-practice issues.
  • If Travis passes, Jenkins will run the full test suite. Jenkins will then trigger the Coveralls build.

We require all pull requests to pass Travis, Jenkins and Coveralls prior to merging.

Details

The checks run for each CI system are:

  • Travis CI
    • make check-clang-tidy
    • make check-format
    • make lint
  • Jenkins
    • make
    • make unittest
    • make coveralls
    • make runbenchmark
  • Coveralls
    • The overall coverage should not drop below 80%.
    • Your PR should not drop coverage by more than 5%.

To ensure that you pass the CI checks, run these commands before you commit. Note that you may need to git add any files that were modified.

  • make check-clang-tidy
    • This runs clang-tidy on your code. It checks your code for common errors and/or bugs.
    • Fix all of the issues that are reported manually.
  • make format
    • This runs clang-format on your code. It will rearrange lines, comments, make sure you're within the line length limit, etc.
    • This automatically formats your code.
    • You should pass make check-format after running this.
  • make lint
    • This runs cpplint, which checks that your code is written in (approximately) Google C++ style.
    • Fix all of the issues that are reported manually.

Note that these checks are not comprehensive, e.g. the above tools struggle to enforce good whitespace habits. We rely on you and on code review to keep the codebase clean.

Labels

When filing issues or opening PRs, you should always tag them with the appropriate tags, to make it easier for everyone to keep track of what's going on.

(TODO: describe labels)

Code Review

TBD

After you merge

(TODO: describe nightly tests and the process of putting out fire if nightly build fails)

Clone this wiki locally