[go: up one dir, main page]
Skip to content

Protected Branch name precedence over wildcard

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Context

When users have a wildcard say release-v1* and a branch rule name release-v1, the most permissive rule applies and the wildcard takes precedence. This is confusing for users who expect most specific name match to take precedence over wildcards.

Users have reported repeated frustration with this:

See #551099 (comment 2583242597).

I wasn’t aware we couldn’t create an exact-match name without the branch existing. I believe that is a bug. We should be allowing any name even if the branch does not currently exist. That’s how protected branches works.

Design Proposal

See #551099 (comment 2584378221).

  • Add the option for users to create a branch rule with a specific name (even if the branch does not exist)
  • Specific branch names should take precedence over the wildcard matches.
  • Update the docs if needed.
Current Proposed: Branch rule creation with branch name

current.png

Users are not allowed to create a branch rule for branches that don't exist

current-wildcard.png

Users are allowed to create branch rules with wildcards

branch-rule.png

Text should say No branches found instead of No results found

Design questions (out-of-scope)

How to determine which rule is best match for a branch?

Keep in mind with protected branch rules there are group-level rules that would be cascading down to projects &8679.

From the order of least to most specific:

  • Wildcard matches
    • Group-level rules
    • Project-level rules
  • Name branches
    • Group-level rules
    • Project-level rules

This pattern of presenting rules like this can be thought of as a funnel with the widest least specific rules at the top and getting narrower and more specific as you go down the list. Examples of this in use is with this comment !52319 (comment 512636614).

To help visualize the precedence order, we would present the protected branches alphabetically in order of precedence order from least to most specific. With 3 rules feat/1234-new, *, and feat/* it would be presented like:

  • * (least specific)
  • feat/*
  • feat/1234-new (most specific)

Handling duplicates

A duplicate would be considered as having the exact same structure. feat/* & feat/* would be a duplicate. For example * & feat/* would have an overlap but are not duplicates.

Feedback required: Similar rule scenario

Suppose you had two rules A) f*ture and B) featu*e and you wanted to match branch feature, which rule would match A or B?

Looking at the rules:

  • A would match names like "future", "feature", "feature/123-new-fixture".
  • B would match names like "feature", "feature/123-new-fixture".

Determining the rules to resolve this scenario would apply to resolve similar real scenarios like this !52319 (comment 510049751) that have matching patterns of *, v*.*.*, v*.*.*.*

These rules do not have the exact same structure so they would co-exist.When rules A and B are sorted alphabetically (A-Z), the result would be:

  • f*ture (A)
  • featu*e (B)

This means rule B would match for branch feature.

It would match because both are wildcards and when ordered alphabetically B is the last rule to match.

Original proposal (outdated)

While using gitlab protected branches with wildcards, the wildcard branch name takes precedence over a fully named branch rule.

e.g. in this demo repo: https://gitlab.com/cy4n/protected-branch-demo

a) i am allowed to push into branch_1, although "no one" is allowed to push.b) i am not allowed to merge into branch_1 without codeowner approval (both points showing that the wildcard branch takes precedence)

image

Expected Behaviour:

the more explicit rule for branch_1 shoulda) forbid me to push as anyoneb) allow me to merge (as a maintainer) without codeowner approval

Edited by Alyssa Trinh