Configuring ACLs for Code Review

Note: This section is for system administrators only.

Part of enabling the GitCentric’s optional Gerrit Code Review functionality involves setting ACLs for Git references as shown in the following table:

Reference	Permission	Setting	Group
`refs/*`	`Forge Author Identity` `Submit`	`ALLOW`	Registered Users
`refs/for/refs/*`	`Push`	`ALLOW`	Registered Users
`refs/heads/*`	`Label Code-Review` (range -2 to +2)	`ALLOW`	Registered Users

Most of these ACLs are set automatically for the All-Projects repository when you install GitCentric.

There are slight differences based on whether you installed GitCentric 2013.3 for the first time, or you upgraded to GitCentric 2013.3 from an existing installation. If you:

Installed GitCentric 2013.3 for the first time, all ACLs listed in the preceding table are set as the default for the system-defined "All-Projects" repository. Any repository that inherits rights from All-Projects is also configured to support code review.
Upgraded to GitCentric 2013.3 from a previous release and you are currently using Gerrit Code Review, you will need to manually set the Submit permission for refs/* as shown in the preceding table. All other permissions (Forge Author Identity, Push, and Label Code-Review) were set as the default for All-Projects when you installed GitCentric.
If you upgraded from a previous release and are not currently using Gerrit Code Review and now wish to, you must manually set all the ACLs listed in the preceding table.

See Configure Access Rights (ACLs) for a Repo for more information.

Once the ACLs are set, all that remains to enable code review is for your users to configure their clones to support code review. See Configure the Clone for Code Review (Optional) for more information.

Additional Considerations for ACLs

There is no one set of ACLs that are appropriate for every installation. You must analyze the needs of your specific installation and adjust the default ACLs as necessary. See the Access Controls topic in the Gerrit Code Review documentation, specifically the section labeled Examples of typical roles in a project for suggestions about setting Gerrit Code Review ACLs.

The remaining information in this section describes other considerations to evaluate when enabling code review.

Label Verified

The Verified category is generally intended to be used in continuous integration environments where Gerrit Code Review is integrated with Hudson or Jenkins. Typically, the vote for this category is set to +1 by the integration tool indicating that it was able to compile and run tests on the change, allowing the change to be submitted. If you do not have a continuous integration environment, you can either disable the Verified category, or configure the Label Verified ACL in GitCentric to allow users to manually specify a vote via the Gerrit Code Review GUI. The ACL to allow manual voting for the Verified category is shown in the following table.

Reference	Permission	Setting	Group
`refs/heads/*`	`Label Verified` (range -1 to +1) ALLOW	`ALLOW`	Registered Users

Configuring "Verify" for Continuous Integration

With Hudson or Jenkins, you would typically set the Label Verified permission for the Non-interactive users group. See the Hudson, Jenkins, or Gerrit Code Review documentation for details about configuring a Continuous Integration environment.

Disabling "Verify"

If you are not using Jenkins/Hudson continuous integration, you can disable the Verified requirement in Gerrit Code Review with the gerrit gsql command:

ssh -p 29418 <your_server.com> gerrit gsql
DELETE FROM approval_categories WHERE category_id = 'VRIF';
DELETE FROM approval_category_values WHERE category_id = 'VRIF';