Add option to disable the merge button for projects

We use a bot to do merging, but the button can still be used accidentally by those with requisite permissions. An option to disable the merge button completely for such projects would be great.

Title changed from Add option to disable the merge buggon for projects to Add option to disable the merge button for projects

mentioned in merge request gitlab-foss!1257 (closed)

mentioned in merge request gitlab-foss!1257 (closed)

mentioned in issue gitlab-foss#2083 (closed)

Added feature proposal in GitLab FOSS label

added ~13921 label

mentioned in issue gitlab-foss#4176 (moved)

I think the big question here is, why do you need a bot to do merging? If you used the "merge when build completes" functionality, and all of your bot's functionality was in your CI job, then this would be unnecessary.

Not all projects fit into the model Gitlab provides for its CI feature set. We have projects which need to test on a wide range of platforms (old unix operating systems, different architectures, etc.) and which can't be put onto a "build every MR ever" train because they're either not our hardware (e.g., generous users contributing these platform builds), or are just too slow (2 hrs+ for a build because it's just old hardware and nothing new can run OS X 10.5, so that's what you're stuck with). Observing those require human intervention (unless Gitlab is going to start analyzing the results for us ;) ) and a simple status indicator isn't going to cut it.

We have a project which consists of 17 different unrelated subprojects. Some of them are in Java, some in HTML some in C++ etc.

We are pushing all this subprojects into project repository as separate branches. Master subproject branches are set as "protected" and can be further branched, which is good.

However, by each of this (subproject-master) branches we have a "Merge" button which opens merge request towards default branch. We'd like to disable this button for subproject (master) branches.

There are few possible things here:

• We are doing it wrong, push different kind of branch? We tried orphan branch but no difference.
• Open 17 different projects? It would be suicidal.
• You dont support this kind of functionality?

We have a project which consists of 17 different unrelated subprojects.

@zbrdar Yes, these should be 17 different projects. You will be much happier once they are organized this way, trust me. You'll also find GitLab more pleasant to use once you're using it correctly.

@JonathonReinhart So your proposal is to create a project group?

https://gitlab.zendesk.com/agent/tickets/71422

added customer in GitLab FOSS label

Feedback from customer in GitLab FOSS

if a project owner/master wants to force merge a change (because of failed pipeline), they will need to manually merge the change. If the project setting ‘Only allow merge requests to be merged if pipeline succeeds’, then the user isn’t provided a merge button if the pipeline is failed.

If no pipeline exists, why would that be expected behavior and default to allow a merge? IMHO, if this is expected behavior, I recommend adding a button to allow project owners to set policy on that behavior. I would lean my policy towards protecting the repository where no pipeline == failed pipeline.

Allowing an administrator to disable the merge button on a project would stop MRs in projects with no pipeline being merged.

added SP3 in GitLab FOSS label

Would that include external statuses or are those also a pipeline (even though Gitlab has no idea what statuses are expected and therefore missing).

I guess my question is:

• Is the "disable" a blanket or
• is it a "disable if no pipeline".

option? I prefer the first since we do use commit statuses, but Gitlab has no idea which are expected and therefore no idea if any are missing. I suppose the latter could be circumvented if a user submits a status to their own MR (see gitlab-foss#3596 (closed) and gitlab-foss#29369 (closed)) causing a "success" pipeline to appear.

Sorry if I'm being a little selfish here, but using the word 'only' in the config description suggests that a pipeline results must exist. There are more reasons to disable a merge button, such as not enough approvers if configured.

Going by Ben's two options, IMHO 'disable' as a blanket. Default to disable and only enable when all required/configured conditions are met.

That sounds sufficient to me as long as we can specify an unsatifiable condition (as far as Gitlab is concerned; the merging mechanisms we have do their own condition verification I wouldn't expect Gitlab to support or even understand).

mentioned in issue gitlab-foss#27371 (moved)

Allowing an administrator to disable the merge button on a project would stop MRs in projects with no pipeline being merged.

Does this mean we have to use disable merge option to prevent merging MRs with no pipeline?

@victorwu - Based on our conversation a couple of months ago (Two Sigma), this is important for us to have given we have a large mono-repo and we need to block users from directly merging. Any chance of this being bumped up in priority? We can't use Merge requests for CR unless there is way to disable this and will have to stick with our existing solution (that we are not happy with :()

@harikmenon : Sorry not totally understanding. Do you mean that you are not merging at all on the merge request page? But you are merging through the command line outside of GitLab?

@victorwu That is approximately correct. Instead of "through the command line", we have a server that does the merges, but only after they have undergone certain checks. Also, there's a complicated thing here with our in-progress hg migration; in fact the migrations are done in hg and then round-tripped back to git. But that bit will eventually go away. The checks must remain. A pipeline is not suitable, because it does not re-run when the merge target (e.g. master) changes. Our internal checks do re-run when necessary.

@dturner_ts : So it sounds like you are doing the merging in git itself (not GitLab), using automated scripts. And you want to continue using GitLab merge requests for people to collaborate right? Add comments, chat about them, etc.?

@smcgivern : To solve the problem above, could we have the merge requests remain in WIP, but have all the merging happen through automated scripts on a server / outside of GitLab? That would help prevent people from mistakenly clicking merge on the merge request page, right?

@dturner_ts does the server do that as a user that isn't a human? (i.e. no-one logs in as that user account.)

If so, it seems like this would be possible with protected branches: set that server user as the only user who can merge to the branch you care about. Other users will see the button, but it will just say something along the lines of 'ask someone with access to merge'. Have you tried that?

@victorwu That is correct.

@smcgivern We'll try that out. Thanks.

@smcgivern @victorwu Unfortunately, protected branches have the side-effect that they disable all non-fast-forward pushes ("force pushes") to the branch, even by the owner. We wish to allow non-fast-forward pushes (by the owner only, of course). Also, I guess we might at some point want the project owner to be able to delete branches, but we're not there yet.

If we had fine-grained access control, we could separate the concepts of non-fast-forward pushes & branch deletions from that of limiting who can merge. But Gitlab doesn't have that right now.

In EE, it looks like there are separate "allowed to push" vs "allowed to merge" settings, so it would be possible to add "allowed to force-push" as an option. Looking at the EE code, it seems like this at present would require a bunch of copy-pasta or refactoring.

We could also separate force-pushes out into an entirely unrelated per-project boolean, which would be easier to implement and could probably be implemented entirely in CE. That's work I'm happy to do, but since it will later have to be rewritten if we want fine-grained controls, I would prefer for someone else to tell me it's OK before I start hacking.

@DouweM @mydigitalself : What do you think about @dturner_ts 's suggestion of having a setting for "allowed to force-push" for protected branches?

added Platform in GitLab FOSS label

FWIW, I like it as long as it is forced to be at least as high the "allowed to push" permission ;) .

changed milestone to %Next 3-6 months in gitlab-foss

@victorwu will give it some consideration in the future once I've managed to digest the use cases and requirements entirely, there seems to be a lot of overlap with gitlab-foss2278651 and gitlab-foss2278654 too so would be good to consider this together.

Oh, right, it seems like we actually would be OK if we just do this in CE. So we might look into it, depending on our schedule. Let us know if someone else starts working on it so we don't duplicate.

moved from gitlab-foss#2456 (moved)