Address: http://www.phabricator.com/docs/phabricator/article/Audit_User_Guide.html
Overview
Phabricator supports two code review workflows: Review (pre-submission review) and Audit (post-Submission review ).
This document outlines the post-Submission review process using the audit tool.
How does audit work?Use the review tool to allow code submission and deployment without waiting for the code review results, although code review is still performed. The audit tool mainly follows two things:
- Code submission (Commits), And their review status (such as "not audited", "approved", and "concern raised )").
- Review request (Audit requests). The review request reminds the user to review and submit it once. It can be triggered in multiple ways. (See the "Audit trigger" section)
On the homepage of the review tool (AT/audit/) or phabricator, you can view code submission and audit requests that need your review. As shown in.
- Necessary review (Required audits). When you are a member of a project or the owner of a package, required audits prompts you to review and submit it once. When you acknowledge this submission, the review request will be closed.
- Submit question (Problem commits). This means that someone is worried about the code you submitted during the review process. When you eliminate their concerns and all reviewers acknowledge the code, the problem submission will disappear.
Example
- Cui Hua made a code submission
- Iron eggs received the review request
- After a while, iron egg logged on to phabricator and saw the review request on the homepage.
- Iron egg checks the Code submitted by Cuihua. He found some problems in the Code. Then he chose the "worry-free" option and described the problems in the comments.
- Cui Hua received an email about her worries about her submission. She decided to handle the problem later.
- Soon after, Cui Hua logged on to phabricator and saw a prompt on the homepage "submit questions ".
- Cui Hua solves those problems in some ways (for example, "ask for discussion" and "fix the problem and submit ")
- Iron egg expressed satisfaction and recognized the initial submission
- The review request will disappear from the iron to-do list. The problem submission will also disappear from the to-do list of Cui Hua.
Audit triggerAudit requests can be triggered in multiple ways:
- Writing "auditors: username1, username2" into the submission comment triggers the above user to receive the review request. As shown in.
- You can create a series of trigger rules in the Herald tool based on the submitted attributes. If a file is created, the text is modified, or submitted by another user.
- You can create an audit request for yourself by submitting comments in any submission.
Review in small teamsIf you are in a small team and think that complex trigger rules are not required, you can create a simple audit workflow, as shown below:
- Create a new project: "code audits ".
- Create a global rule for code submission: "differential revision" "does not exist ". Under this rule, each submission of the "Code audits" project triggers an audit request.
- All engineers join the code audits project.
In this way, all project members will receive each code submission review request. However, once a Member approves this submission, all the review requests will be cleared. In fact, this method forces everyone to abide by a rule: Any submission should be visible.
Once the team grows, the trigger rules can be improved so that each developer can only see the code modifications related to them.
Review Tool tips:
- Sense of responsibility. When you review a code submission, the audit you are responsible for is highlighted. You are responsible for any audit.
- In the diff Comparison area, click the row number to add embedded comments.
- In the diff Comparison area, drag a row number to add embedded comments that span multiple rows.
- Embedded comments are initially saved as drafts until you submit comments at the bottom of the page.
- Press "?" Key to view the shortcut key.
