Spike: Explore wildcard pattern and non-protected branch support for Merge Request Approval Policies

Background

Currently, Merge Request Approval Policies (MRAP) only support:

• Protected branches with exact name matching
• The branch_type: protected option to target all protected branches

This creates limitations for organizations with:

• Complex branching strategies using naming conventions (e.g., release/*, feature/*)
• Workflows involving unprotected branches (e.g., stacked branches: develop ← feature/a ← feature/b)
• Branch protection rules that already use wildcard patterns

Related issues:

• #535305 - Feature request for wildcard pattern support
• #585556 - Request to expand MRAP to cover all branches

Customer impact:

• Multiple customers blocked from migrating to centralized Security Policies
• Forced to maintain split configurations (per-project rules + policies)
• Cannot enforce approval requirements on unprotected feature branches
• Administrative burden of manually listing every branch

Spike Objectives

Investigate what would be needed to add support for:

1. Wildcard pattern matching for branch names in MRAP (e.g., release/*, feature/*)
2. Non-protected branches as valid targets for MRAP rules

Investigation Areas

1. Wildcard Pattern Support

Explore:

• Can we reuse existing GitLab branch protection wildcard logic?
• How do other policy types handle wildcards? (e.g., branch exceptions in Scan Execution Policies)
• How should wildcard patterns in policies match against wildcard patterns in branch protection rules?
  • Example: Policy defines release/*, branch protection defines release-* - how should these interact?
• Conflict resolution when multiple overlapping patterns exist (e.g., de* vs dev*)
• Pattern precedence rules (should more specific patterns override general ones?)

Technical considerations:

• Pattern matching implementation approach
• Validation and testing functionality for patterns
• Backward compatibility with existing exact-match policies
• UI/UX for pattern configuration and validation

2. Non-Protected Branch Support

Explore:

• What are the architectural implications of evaluating policies against non-protected branches?
• Performance concerns and mitigation strategies:
  • Querying all branches on every policy evaluation vs. alternative approaches
  • Caching mechanisms
  • Event-driven updates (e.g., on branch creation/MR creation)
  • Pattern matching at MR creation time vs. runtime evaluation
• Security and compliance implications
• How does this align/conflict with broader product direction around protected branches?

Customer use cases to validate:

• Stacked branch workflows (develop ← feature/a ← feature/b ← feature/c)
• Centralized group-level approval requirements for all branches
• Migration path from per-project rules to Security Policies

3. Cross-Cutting Concerns

Explore:

• Database schema changes required
• API changes and versioning
• Policy YAML schema updates
• Migration strategy for existing policies
• Potential reusability for other policy types in the future
• Edge cases and error handling

Deliverables

1. Proof of Concept (POC)

   • Demonstrate wildcard pattern matching for protected branches
   • Demonstrate policy evaluation for non-protected branches
   • Include basic pattern matching scenarios

2. Written Investigation Summary

   • Technical approach and architecture proposals
   • Performance analysis and risk assessment
   • Effort estimates for full implementation
   • Recommended implementation phases (if applicable)
   • Identified blockers or dependencies
   • Security and compliance considerations

3. Decision Documentation

   • Recommended path forward (or reasons not to proceed)
   • Trade-offs between different approaches
   • Alignment with product strategy

Success Criteria

• Clear understanding of technical feasibility for both wildcard patterns and non-protected branches
• Documented performance implications and mitigation strategies
• Working POC demonstrating core functionality
• Effort estimates for full implementation
• Recommendation on whether to proceed and in what phases

Timeline

Target milestone: %18.11

Labels

spike groupsecurity policies Category:Security Policy Management typefeature featureenhancement backend workflowrefinement