1

I have a many repos all of which can be edited by a different "Senior Review Group" group. I've detailed this idea here. Should I use the GitLab Group functionality to assign reviewers are say who can merge? Or should I create external tooling around this?

A big concern I have is that a Group in GitLab seems to be focused on Development. But for example a "Senior Review Group" will never produce code.

Evan Carroll
  • 2,091
  • 3
  • 22
  • 65

1 Answers1

1

I have followed this pattern in the past for LDAP synchronisation, where a "permission" group was synched with LDAP and then invited into a "projects" group with a specific role.

This used the Gitlab ldap group synch feature.

There are a few benefits over adding users directly:

  1. you can manage identities exclusively in the IdP (e.g. Active Directory) - onboarding/offboarding/privilege escalation all done from the IdP.
  2. You make simple declarative statements about which (user) groups need to be in which (project) groups, with given roles.
  3. This makes it easier to think about the authn/authz model and indeed makes it feasible to write declarative infrastructure as code for the configuration of the projects themselves -- which group can merge, which branches are protected, etc.

On the topic of a "senior review" group which will never produce code - I agree this is a tricky permission to model. You want someone who can approve merge requests and perhaps merge them (thereby effectively making a commit and therefore "producing code" however). However, it's called privilege escalation, when what you want is true role-based authorization. I'm not sure you can do that yet with Gitlab.

Bruce Becker
  • 3,573
  • 4
  • 19
  • 40