GitLab Permissions - Pushing, Pulling and Merging

So I’m a bit confused about GitLab Permissions here.

• Everyone can “Pull project code”. What constitutes Project Code? Does that include ALL files?
• Everyone except Guests can “Pull packages”. Could someone explain to me what a Project Package is?
• Only Developers, Maintainers and Owners can “Pull container images”. What are Container Images?
• Developers, Maintainers and Owners can Approve, Manage and Accept Merge Requests. This honestly troubles me a bit, and I’m curious if I can setup GitLab so only Maintainers and Admins can accept Merge Requests.

I’m part of a 50+ Development Team. Right now everyone is a Developer, except for Department Leads who I’ve setup as Maintainers (and myself and 1 other guy who as Owners, as we are Team Leaders and owners of the GitLab Server). I’m quite worried I’ve given too much permissions to some of our Developers, such as the Artists who have very little to no real technical knowledge and who should just have enough Permissions to Pull all the Project Files. I would also personally like it so Developers can send Merge Requests, but only a select few Maintainers could actually accept those Merge Requests. So …

1. Are Guests and Reporters able to pull all the files in a GitLab Project? And if not, could I set it so they could? I would prefer to have my Artists, Sound Designers, etc, who have minimal technical knowledge, unable to make Pushes at all, much less Approve, Manage and Accept Merge Requests, but still able to Pull the Project. I don’t know if I’d even want them to be able to create Branches either.
2. Could I set it so Developers cannot Approve, Manage and Accept Merge Requests? I would prefer to only allow a select few on my Team who truly understand Git to Approve, Manage and Accept Merge Requests. So Developers would make up the Coders on our Team, and I want them to be able to Push and make Merge Requests, but only the Maintainers (and Owners) could approve their requests.

Hi @naupe,

I will go through all your questions:

1. Yeah, the project code includes all files on all branches.
2. A project package allows you to use GitLab as a private repository for common package managers. See also here
3. With the GitLab Container Registry, every project can have its own space to store Docker images. See also here
4. Everyone can approve a merge request. An approval does not mean the request will be merged. You can set up that only Maintainers can merge the requests.

1. You can set up the permissions per project for every group in the repository settings. To do this, in your project go to Settings → General → Visibility, project features, permissions.
2. In the GitLab premium tier, there are approval rules for merge requests. In the lower tiers, you only have the options given in the point above.

I hope I could help, let us know if you need further help.

@Th3Ph4nt0m Thank you for answering my email!

That’s a shame to read that GItLab Premier is required to setup Approval Rules for Merge Requests, but GitLab has to make their money.

So I went to Settings → General → Visibility, project features, permissions on our project, but I found that all the Dropdown Options were greyed out:

GitLab_Greyed-Out918×846 27.5 KB

Why is that? Can it be fixed? I’m logged in as a Project Owner, Project Visibility is set to Private (which I can’t seem to change either) and we’re on GitLab Community Edition 12.2.1 (Yes, I know our GitLab is quite out-of-date, but I’m holding out on updating until after some major pushes that are being done on our GitLab are complete).

Hi @naupe,

to edit the access to project features, your project needs to be internal or public. Every private repository has its default settings to “Only Project Members”.

@Th3Ph4nt0m In Project visibility, under Visibility, project features, permissions, I have the options of Internal and Public, but they are greyed-out and I can’t select them.

GitLab_Greyed-Out2922×374 14.7 KB

Any idea why that is?

Also what are the differences between a Public, Internal and Private Project Visibility?

The project visibility regards to the group visibility settings.

Public means everyone (logged-in and not logged-in) can see and clone your repo.
Internal means that only logged-in users (that are not set as external in the admin settings) can see and clone what you have set up.
Private means that only project members have access to your repo.

You can read more about this in this documentation article.

Conclusion: Your project seems to be part of a group. A project’s visibility cannot override the groups settings, so you need to update the visibility of your group.

OK @Th3Ph4nt0m, I set the Group to Internal and the Project to Internal as well.

So are there supposed to be anymore settings out of the following? I set everything to Only Project Members, but I don’t see anything about Pull Permissions.

Visbility1024×1385 49.2 KB

Hi @naupe,

there is actually no permission for “Pull” (I think you mean cloning the code to your machine).
Everyone who has access to the code, which would be permission “Repository” (View and edit files in this project), can clone it. I don’t see why you should be able to set viewing and clone permissions separately.

If you want to block users from pushing/merging into specific branches, you can use the branch protection in combination with the project members permissions.

That’s fine. I want everyone in the Group to be able to Pull, but not everyone should be able to Push or Merge.

Aha, protecting branches. THAT’S what I want!

OK, I’m setting master (and another important Branch) with Maintainer as the only one to be able to Push and Merge to these Branches. This helps immensely, thank you so much @Th3Ph4nt0m !