Disassociating a policy project means Gitlab will silently ignore it when re-applied for existing MRs
Summary
Projects seem to silently ignore previously applied security results policies in external policy projects once applied=>unapplied=>reapplied. The policy shows up in the project configuration but MR gating does not function.
Steps to reproduce
- Create a project, create a branch, create an MR with security scanning
- Introduce a security finding into the MR code
- Apply a security policy project with a security results policy that blocks on the above finding
- See the security results policy applied in the MR project (Security & Compliance > Policies)
- Refresh to see the MR blocked without approval
- Disassociate the policy project from the MR project
- Refresh to see the MR unblocked
- Re-associate the same policy project and policy with the MR project
- See the security results policy applied in the MR project (Security & Compliance > Policies)
- Refresh to see the MR ignore the policy and not block as expected
Example Project
Cannot as requires pay for features
What is the current bug behavior?
Projects with policy associated silently ignore in MRs while still appearing applied at the project level
What is the expected correct behavior?
The current policy associated with a project must be applied.
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com
Results of GitLab environment info
NA
Results of GitLab application Check
NA
Possible fixes
-
backend Call Security::SyncScanPoliciesWorkerwhen policy project is updated or assigned for first time
Edited by Sashi Kumar Kumaresan














