Introducing TeamForge Project Scope into Gerrit – Welcome to cross repo dashboards and RBAC

If you ever wondered how

• you can see Gerrit change requests of different repositories but same TeamForge project in one dashboard/report

• you can assign custom Gerrit access rights to project role so that they apply to all Git repositories within the same TeamForge project

• you can make a Git repository visible to all project members of this TeamForge project but not to all members of the entire site (default access permissions)

… read on.

Fortunately, our blog posts are not just a one way street, unidirectional information broadcasting mechanism. We are listening to your comments and will turn your feedback into new features. This blog is about a feature “TeamForge project scope in Gerrit” that initiated out of multiple blog comments, support tickets and conversations with customers.

We often got approached regarding our Eclipse Desktop and GitEye which allow you to see Gerrit changes/reviews across repositories, grouped by TeamForge project.

In the screenshot above, you can see changes out of two different Git repos (teamforge-git-integration and gerrit-workflow) which reside in the same TeamForge project (Git Integration Development). Users asked whether we could have a similar functionality directly in Gerrit Web UI and we are happy to show how this looks like in the two following screenshots.

In all Gerrit projects, you can now click on the Dashboards section and see four dashboards which group all changes of the parent TeamForge project. If you click on All Changes Open, you will see something like this:

This screenshot is similar to the Eclipse/GitEye one, showing Open reviews out of gerrit-workflow and teamforge-git-integration.

To implement those dashboards, we had to tell Gerrit what it means for two repositories to be in the same TeamForge project. We did that by introducing Gerrit parent projects which map to TeamForge projects. The following screenshot shows some of those projects (they are named by TeamForge project id as Gerrit projects need an immutable name, the more human readable TF project path is shown as project description).

All Git repositories that belong to the same TeamForge project will be children of the corresponding project in Gerrit and inherit both access rights and dashboards.

Did I just say inheriting access rights? That’s right, you can now define custom Gerrit access rights that inherit down to all Git repositories of the same TeamForge project which brings us to another frequently asked feature. Let’s have a look at the default access rights in a Gerrit parent project:

 As you can see, we have introduced some new groups, which contain all TeamForge project admins / project members  of that TeamForge project. Only TeamForge project admins can add custom access rights at this level. As a side effect, they can now also change access rights on all contained Git repositories without needing SCM Admin permissions any more. TeamForge Project members get access to the dashboards we have discussed above.

As a project admin, you can now go ahead and add additional access rights here which will inherit down to all Git repos in this TeamForge project. Want to grant Push Merge Commit access rights to all members of the Developer role for all Git repositories in TeamForge project Git Integration Development? The next screenshot shows you exactly that.

Of course, you can also use the newly introduced project admin and project member groups on the individual repository level. Let’s say you like to grant all TeamForge project members of Git Integration Development (project id proj1012) read access to the gerrit-workflow repository. The next screenshot shows how this would look like.

These are just some examples what you can do with the new Gerrit project hierarchy and groups, we are sure you will see how to realize any kind of default access permission scheme with that approach.

Some technical details at the end:

The features described are available from TeamForge Git Integration 8.1.4 on. There is no need to reboot TeamForge to upgrade Gerrit. If you do a fresh install, the feature will be enabled by default. If you do an upgrade you have to edit gerrit.config and add

syncTeamForgeProjectHierarchy = true

in the [teamforge] config section (and restart Gerrit).

If you decided to disable the features again

teamforge.syncTeamForgeProjectHierarchy = false

the created TeamForge parent projects will not be deleted but affiliation for project membership and project admin groups will no longer be calculated and any operations affecting project hierarchies (like moving a Git repository to a different TeamForge project) will be ignored.

Let’s hope you will never want to disable those features again though. If you have any feedback, just drop a comment.