Migrating a fairly sophisticated Gitolite permissions scheme?


I’ve been investigating migrating a large code base with ~100’s of git repos from a Gitolite-based solution to a Gitlab hosting environment. I’ve been experimenting with Gitlab a bit, and have been struggling to find an elegant solution to the current dev-ops that we have in place. I could use some advise on perhaps top-level ops concept that would be more compatible with Gitlab, or perhaps some feature sets that in Gitlab that I’m not familiar with.

So here goes:
We are operating a “software factory” type of solution where each git repo is considered a component with its own set of tests, etc… Various programs within the company integrate these components together in various different ways to build their integrated product, thus an integrated product is comprised of ~dozens of git repos together. We use a system similar to Google’s “repo” to manage the relationship of these repos, where parent repos can claim dependencies on child repos via a manifest at the repo root.

We try to manage the chaos of various different programs all having their fingers in the pot on these git repos currently using Gitolite branching permissions. In a nutshell, we create groups of users associated with particular programs in the company, and then create branch access rules that give users on a program write-access to the program-specific “int” branches in a repo, which indicate the current commit that any particular program has integrated to their product. For example, consider a “Program A” and “Program B”. We could see in any particular repo a prog_a/int and/or a prog_b/int branch.

We then typically enforce that the master branch is the bleeding edge of the repository, and in an effort to prevent excessive forking of these projects, enforce that program-specific remain ancestors of the master branch. This has the effect of forcing the various programs to work together to maintain the master branch.

We typically nominate owner(s) for each git repo, who have the responsibility for maintaining the master branch, while folks deployed to their various programs maintain their /int branches. They can take updates from master on an as-needed basis, but are not forced to.

So with that explanation above, I’ve been investigating migrating to a Gitlab hosting solution and have come across some challenges:

  • The membership model of Gitlab doesn’t seem to be quite compatible with this concept. Would be nice to be able to define a group of users called “prog_a_devs”, then give that group write-access to branches “prog_a/int” across all repos (likewise for prog_b). Is there perhaps a way to link protected branches to a specific group? (Currently we can define these groups either in our Active Directory system, or the Gitolite configuration file)

  • I’m struggling to find a hook for implementing custom workflow rules like I mentioned above, for example “**/int* branches must remain an ancestor of dev”. I do have a script that implements these types of checks, which were integrated to Gitolite using it’s VREF mechanism. I have experimented with using these scripts in a Gitlab merge-request pipeline, and have had some success there, but I’m worried about only enforcing at the merge-request level, and not at a direct-push level.