Add Merge Request creation rules
Problem to solve
As a project maintainer I see a lot of MRs created from forked projects from branches named like patch-1
, my-patch
or even directly from master
.
While for some projects this is probably fine, I'd prefer to prevent such branches from being used. This makes the history review really hard, because when going through Git log, all I see is the Merged 'master' into 'master'
or Merged 'patch-1' into 'master'
commit subjects. It lacks a lot of context. The biggest problem is that it's impossible to find out what's happening on the main branch or quickly find when a certain change was merged without looking into details of the merge commit.
So I'd like to have a mechanism in GitLab that would prevent a creation of the MR, giving the author a clear explanation, basing on some per-project defined rules. For example: checking against a list of disallowed branch name patterns.
I could of course add a CI task that would fail if a specific branch name would be used. But since we can't change the source branch - only the target - finding such case after the MR is created brings more additional work. The user must close the MR (or the maintainer must find all MRs in that state and close them - even worse), then push a new branch, open a new MR filling again the description, adding wanted labels etc.
It would be much easier if such check could be done before the MR is created, when one can simply push the changes under a new branch and change the source in MR form.
During a discussion on Slack the Push Rules feature was mentioned as a potential solution for the problem. However, the rules can be defined only for pushed done directly to the project. This would work to prevent unwanted branch names within project team members. But it would not work for MRs coming from forks from non-team members. And this is the case that I find most problematic
Intended users
Further details
Proposal
We create a concept of "Merge Request rules". At first iteration we allow to implement a list of allowed and/or disallowed patterns for the source and target branch name. The rules are maintained in Project settings, similarly to how we define Push Rules currently.
When such rules are defined, the Merge Request is validated before it's being saved. If any of the rules is not fulfilled - for example the source branch is set to master
when the rule disallows it - the Merge Request creation form fails validation and prints a clear message to the user which rule was violated.
Permissions and Security
The definition of rules should be defined similarly to how Push Rules are defined. This means it would require a Maintainer and above permission within the project/group.
Documentation
Availability & Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Links / references
Related to #8531