Use merge base pipeline for scan result policy comparison
Why are we doing this work
Currently, when enforcing approvals through scan result policy we consider the latest head pipeline (main tip) in the target branch. But, the security MR widget uses merge base pipeline which causes inconsistencies between the results shown in MR widget and the approvals. As a part of this issue we want to change the behaviour to use merge_base_pipeline
for scan result policy to stay consistent with MR widget
Relevant links
Non-functional requirements
-
Documentation: -
Feature flag: Create scan_result_policy_merge_base_pipeline
feature flag and implement the changes behind the feature flag -
Performance: -
Testing:
Implementation plan
-
backend Update UpdateApprovalsService#target_pipeline
to usemerge_request.merge_base_pipeline || merge_request.base_pipeline
-
backend Create a new sidekiq worker Security::ScanResultPolicies::SyncMergeRequestApprovalsWorker
and invoke it fromSecurity::ScanResultPolicies::SyncFindingsToApprovalRulesService
instead of callingUpdateApprovalsService
directly -
backend Update Security::ScanResultPolicies::SyncFindingsToApprovalRulesService
to invokeSecurity::ScanResultPolicies::SyncMergeRequestApprovalsWorker
and create a function to get MRs targeting the target branch of the pipeline's ref and invoke the worker for those MRs
def merge_requests_for_target_branch
pipeline.project
.merge_requests.opened
.by_target_branch(pipeline.ref)
end
Verification steps
-
Create a new project without any already existing vulnerabilities -
Create a scan result policy to require approval when a new vulnerability is detected -
Create a new MR targeting default branch and make some dummy changes -
Add a commit to the default branch that introduces a new vulnerability -
Create a new pipeline in the MR's source and verify if the MR widget does not show newly introduced vulnerability and approvals are not enforced from scan result policy
Edited by Sashi Kumar Kumaresan