MR approval policies incorrectly block when target branch has no pipelines

Summary

When using unblock_rules_using_execution_policies in merge request approval policies, MRs are incorrectly blocked when the target branch has no pipeline history, even though the policy tunning should prevent blocking in this scenario.

This occurs in imported projects (from non-GitLab sources) where no pipelines have ever run on the target branch, and GitLab doesn't seem to recognize that as it would for a newly (non-imported) created project.

Steps to reproduce

  1. Import a project from a non-GitLab source (GitHub, Bitbucket, etc.) to GitLab.com
  2. Configure the target branch (e.g., main) as a protected branch requiring Maintainer role to merge
  3. Set up a merge request approval policy with unblock_rules_using_execution_policies enabled
  4. Do not run any pipelines on the target branch (leave it in its post-import state)
  5. Observe that the MR is blocked due to missing scan results, despite the unblock rule

Example Project

dnldnz_ultimate_group/compliance-group/push-mirror2!2

What is the current bug behavior?

The merge request is blocked because the required security scans are missing. The target branch shows "No pipelines" and the approval policy treats this as a failed scan requirement, blocking the MR even though unblock_rules_using_execution_policies is configured.

What is the expected correct behavior?

When the target branch has no pipeline history (shows "None" for pipelines), the unblock_rules_using_execution_policies setting should recognize this state and ignore scan requirements for approval purposes. The MR should not be blocked due to missing scans when there's no baseline pipeline data to compare against.

This is particularly important for newly imported projects where establishing an initial pipeline baseline shouldn't block legitimate development work.

Relevant logs and/or screenshots

Screenshot_2025-11-25_at_22.02.41

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

GitLab.com version: 18.7.0

Possible fixes

The approval policy evaluation logic should check if the target branch has any pipeline history before enforcing scan requirements. When target_branch_pipelines == None, the unblock_rules_using_execution_policies behavior should treat this as a valid scenario to bypass scan-based blocking.

Edited Jan 28, 2026 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading