Allow null pipeline for pre scan verification
What does this MR do and why?
We are creating a pre-scan verification for DAST scans as described in issue #366456.
In MR !103063 (merged), we added a new table to store the pre-scan verification details.
This table has a loose foreign key to the ci_pipelines
table that can not be null.
However, after the table creation, we realized that we must create the dast_pre_scan_verification
before the pipeline.
The pre_scan needs to send the dast_pre_scan_verification
to the analyzers so they can send the pre-scan results to the callback
endpoint we will create as part of issue #366456.
The callback endpoint will receive the ci_pipeline_id
and associate the dast_pre_scan_verification
to the ci_pipeline
.
This MR allows the ci_pipeline_id
to be null to support the pre-scans workflow.
Migration
Up
main: == 20230203145514 AllowNullPipelineIdToDastPreScanVerification: migrating =====
main: -- change_column_null(:dast_pre_scan_verifications, :ci_pipeline_id, true)
main: -> 0.0015s
main: == 20230203145514 AllowNullPipelineIdToDastPreScanVerification: migrated (0.0017s)
Down
main: == 20230203145514 AllowNullPipelineIdToDastPreScanVerification: reverting =====
main: -- change_column_null(:dast_pre_scan_verifications, :ci_pipeline_id, false)
main: -> 0.0024s
main: == 20230203145514 AllowNullPipelineIdToDastPreScanVerification: reverted (0.0035s)
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.