Skip to main content

​
What does the rapid-review check show?

Each reviewed push gets a check named rapid-review. Its title gives the result, such as “2 findings posted”, “No findings” or “No new findings”. Its summary gives the mode the review ran in and how many parts of the change (“units”) were reviewed. On later pushes it opens with a line such as “2 of 3 earlier findings addressed, 1 open, no new findings.” Below that, where they apply, the check lists:
  • findings not tied to a changed line;
  • findings below the severity floor;
  • what the pull request says it does, matched to the change;
  • the learnings the reviewer was shown;
  • findings fixed since the last review;
  • warnings, such as files that weren’t reviewed or a .rapid-review.yml that was ignored.

​
What do the check’s colours mean?

  • Green (success): the review ran. Its findings are on the pull request and don’t change the colour, so a green check can come with findings. A review that left part of the change out is green too, and so is one that reviewed nothing for a reason other than those under red, such as answers that couldn’t be read. Its summary says what it left out.
  • Red (failure): the review reviewed nothing because the review service couldn’t be used (it refused the requests, was unavailable or busy, couldn’t be reached, or didn’t answer in time), or the review stopped and couldn’t finish.
  • Skipped: the push wasn’t reviewed. The check’s summary says why.
  • Cancelled: a newer push replaced the review before it finished.
If your branch protection requires the rapid-review check, a red check blocks merging until a re-run reviews the change.

​
What is the claims table in the check?

Rapid Review reads what the pull request’s title, description and linked issues say it does, and the check shows a table that matches each claim to the part of the change that does it. The table also shows:
  • a claim about behaviour or an API that no part of the change does, as not found;
  • changed parts that no claim covers;
  • tests the change skips or removes;
  • tests the description mentions where no test file changed;
  • places where the description and a linked issue disagree.
The check notes that this matching isn’t calibrated, so a claim shown as not found may be done in a way Rapid Review didn’t recognise. A pull request without a description or linked issue is reviewed without claims, and the check says why.

​
What is in the review and its inline comments?

Each finding is an inline comment on the line it’s about, with its severity, an explanation and a fix in words. Where the fix is a small, exact code change, the comment also carries a GitHub suggestion that you can commit. The review’s own text lists the findings it posted, then the findings it couldn’t tie to a changed line (each with its explanation), then what it left out and why. The review is a plain comment: it never approves a pull request or requests changes. If GitHub refuses the review, the findings are listed in the check instead, and the check says so.

​
What is in the summary comment?

Rapid Review keeps one summary comment on the pull request. It’s posted when the first review starts, says that the review is running, and is updated on each push.
  • The first line, in bold, says how many new findings the push raised and how many earlier findings are still open.
  • A few sentences on what the pull request does.
  • Folded sections: where the change does what the description says, what each part of the change does and, for some changes, a diagram of the change.
  • Tests the change skips or removes.
If a review can’t finish, the summary comment says so and that its check says why.

​
Will the same finding be posted twice?

No. A finding that’s already on the pull request, or was resolved on it, isn’t posted again. The check says how many findings weren’t posted again for that reason.