Code review tool Phabricator

Overview
Phabricator supports two code review workflows: "review" (pre-commit review) and "audit" (post-commit review).
This document outlines the post-commit review process implemented through the Audit tool.

How Audit Works

Using review tools allows code to be submitted and deployed without waiting for code review results, although code reviews will eventually occur. The Audit tool mainly tracks two things:

• Commits , and their review status (eg "Not Audited", "Approved", "Concern Raised") .
• Audit Requests . A review request reminds the user to review a submission. It has multiple triggers. (see section "Audit Triggers")

On the home page of the audit tool (located at /audit/) or the home page of phabricator, you can see code submissions and audit requests that need your review. As shown below.

• Required Audits . When you are a member of a project, or the owner of a package, Required Audits prompts you to review a commit. When you approve the submission, the review request will be closed.
• Problem Submits . When someone expresses concern about your code submission during the review process. Issue submissions will disappear when you clear their concerns and all reviewers agree on the code.

Example

• Cuihua made a code commit
• Iron Egg received a review request
• After a while, Tidan logged into Phabricator and saw the review request on the homepage
• Iron eggs check the code submitted by Cuihua. He found some issues in the code, after which he chose the "raise concern" option and described the issues in the comments
• Cuihua received an email about Tie Dan expressing concern about her submission. She decided to deal with it later
• Soon after, Cuihua logged into Phabricator and saw a prompt under "Submission of Questions" on the homepage
• Cuihua solved those problems in some way (such as "find iron eggs to discuss", "fix problems and submit")
• Tidan expressed satisfaction and endorsed the original submission
• Review requests will disappear from Iron Egg's to-do list. Issue submissions will also disappear from Cuihua's to-do list

Audit triggers

Review requests can be triggered in a number of ways:

• Writing "Auditors: username1, username2" into the submission comment will trigger the above user to receive an audit request. As shown below.

　　

• In the Herald tool, a series of triggering rules can be created based on the submitted properties. If the file was created, the text was modified, who submitted it, etc.
• In any commit, you can create a review request for yourself by submitting a comment.

Review in small teams

If you're on a small team and don't think complex triggering rules are needed, you can create a simple review workflow like this:

• Create a new project: "Code Audits".
• Create a global rule for code commits: "Differential Revision" "does not exist". Under this rule, each commit to the "Code Audits" project triggers an audit request.
• All engineers join the Code Audits program.

     In this way, all project members will receive a review request for each code commit, but once a member approves the commit, all review requests will be eliminated. In effect, this approach enforces a rule: any commit should be seen.

     Once the team grows, the triggering rules can be improved so that each developer only sees the code changes relevant to them.

 

Review tool tips:

• sense of responsibility. When reviewing a code commit, the review you are responsible for is highlighted. You are responsible for any auditing actions by yourself.
• In the diff area, clicking on the line number will add an inline comment.
• In the diff area, drag on line numbers to add inline comments that span multiple lines.
• Inline comments are initially only saved as drafts until you submit a comment at the bottom of the page.
• Press the "?" key to view the shortcut keys.

 

 

 

 The phabricator  tool is similar to the reviewboard, and there are also command-line tools that can submit code requests.

advantage:

1.  In phabricator  , the diff is also displayed by submitting a request for reivew. But his diff is not the entire content of the file, but only the part of the diff, so there is no need to add a library to the tool in advance, you can submit the diff directly, or you can paste the content of the diff to submit.

2. Not only code review tools, but also bug tracking, wiki and other functions. Unit testing can be done directly, and the association between bugs and code reviews

3. Clear classification by request status, easy to use search function

4. Support svn and git

shortcoming:

1. The user does not support domain settings and needs to be added by an administrator

2. diff is not the entire content of the file

3. Not related to the code base, it is difficult to do statistics and coverage

4. There is no eclipse plug-in, and other relevant information is less

Conclusion: Compared with the reviewboard, the integration with other tools is more powerful, but there is no obvious advantage. It can also be seen that the tools and modes of code review are similar, and they are not as mature as the reviewboard when considered comprehensively.