Wildcard branch protection rules should not apply on top of branch-name rules
Problem to solve
Protected branches: exact branch name permissions should not be extended by wildcard branch permissions.
Target audience
-
Delaney, Development Team Lead, https://design.gitlab.com/research/personas#persona-delaney
-
Devon, DevOps Engineer, https://design.gitlab.com/research/personas#persona-devon
-
Sidney, Systems Administrator, https://design.gitlab.com/research/personas#persona-sidney
Further details
Suppose you want all release branches to be protected, and only allow group X to merge or push on them. You thus create a wildcard rule release/*
to protect them with appropriate permissions.
Now you have release/1.0
that you want to freeze, optionally allowing specific people only to make changes in case of emergency.
It is not possible to implement this freeze because release/*
will still allow the group X to make changes.
I'm not sure whether this is actually intended or not as the documentation only mentions the case where 2 wildcards apply:
Two different wildcards can potentially match the same branch. For example,
*-stable
andproduction-*
would both match aproduction-stable
branch. In that case, if any of these protected branches have a setting like "Allowed to push", thenproduction-stable
will also inherit this setting.
Proposal
If a branch is protected based on its exact name, wildcard protection rules should not apply to it.
Alternatively, there could be a rule to pick only the most specific match, but this could be considered a regression if people are actually using the multiple matches feature (are they?).
What does success look like, and how can we measure that?
It should be possible to restrict a specific branch more than what a matching wildcard allows.
What is the type of buyer?
Same as for branch permission management.
Links / references
gitlab-ce#18193 gitlab-ee#179