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
- Import a project from a non-GitLab source (GitHub, Bitbucket, etc.) to GitLab.com
- Configure the target branch (e.g.,
main) as a protected branch requiring Maintainer role to merge - Set up a merge request approval policy with
unblock_rules_using_execution_policiesenabled - Do not run any pipelines on the target branch (leave it in its post-import state)
- 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
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.
