Private Git and Gerrit

Overview

The linaro private git service is used to host private repositories. Teams can host repositories here that only other members of the team can view.

The service is composed of two components:

* https://dev-private-review.linaro.org/: server to support code reviews.

* https://dev-private-git.linaro.org/: git server backed by gitolite (ssh only), integrated with https://dev-private-git.linaro.org/ for repository browsing.

These components can be used either on their own, or together.

Setting up Team to Access Private Service

To get their space set up on private service, a particular Linaro team should provide:

1. Their Linaro LDAP group name, to control access to private projects.

2. URL prefix, under which all team's projects will be hosted (usually should match a short team name).

3. Combination of services a team wants to use. Quick guidelines:

Gitolite only: A team obviously won't be able to use Gerrit review service.
Gerrit only: Due to access control constraints, a team won't be able to create projects and will need to recourse to Systems team for that.
Gitolite & Gerrit: A team will be create projects via Gitolite, but due to the same access control constraints, they won't be able in Gerrit without request to Systems team. At least in the meantime, a team will be able to push the code, etc. This is thus default, recommended setup. Drawback is that access controls essentially have to be duplicated in Gitolite and Gerrit, so if access control requirements are different from default setup, we recommend to switch to Gerrit only setup instead to ease maintenance, and remove confusing and security risks due to user errors.

Creating Projects

The only way to create projects is via Gitolite, if corresponding service/permission is enabled. Otherwise, creation of a project should be requested from Systems team. As this matter concerns ''private'' service, usual request process (submitting an LSS ticket via https://projects.linaro.org) may be bypassed, and request made directly via email to ''systems@linaro.org''.

A project created via Gitolite, it still needs to be registered in Gerrit via request to Systems team (see above).

General Usage

Usage of private Gitolite and Gerrit services is similar to usage of Linaro public services:

The obvious difference is much tighter, and more detailed, access controls. That means that every user should be ready to check his or her permissions if some operation doesn't work as expected.

Team members can view what repositories they have access to with:

ssh git@dev-private-git.linaro.org info

You'll see an entry similar to:

R W C <your team>/[a-zA-Z0-9].*

Which shows that you can create repositories under this namespace.

For more information about interacting with gitolite see the main git (old wiki-archive article) documentation. You'll need to substitute "git@dev-private-git.linaro.org" for the URL in commands listed on that page.

Deployment Details

Gitolite

The requesting team must provide 2 pieces of information:
* the ldap team for who has permission
* the namespace in gitolite the repositories go under

repo tcwg/[a-zA-Z0-9].*
C = @tcwg-leads
RW+ = @tcwg-leads
# If you want the team to have a split between approvers/developers you can enable:
# R = @team-toolchain
- = @all
option deny-rules = 1

Gerrit

By default, newly created repositories in gitolite will not show up in Gerrit. This is because gerrit uses its own set of permissions on repositories without any knowledge of gitolite. To prevent accidental information leaks the systems team will add repositories to Gerrit at the request of a team.

When a team first requests private git access a base project should be created in Gerrit for this team. The project configuration should look like:

If the project needs an approver/developer split then it can be done with permissions set like:

With the base project created properly, new repositories can be added with this project as the parent and gerrit should grant the team the appropriate access.

The way we create projects in Gerrit leaves "Administrators" as the "Project Owner". This is important to keep because making the actual team an owner would give them too much access and potential for information leaks.