Run migration to purge `security_scans` associated with findings without `finding_data`
Why are we doing this work
As we are planning to use only the security_findings
to generate HTTP responses by using the finding_data
column, we need to make sure all the succeeded security_scans
records on self-hosted GitLab installations have this column populated. This is not an issue for GitLab.com as all the records already have this column set but there is no guarantee for the self-hosted installations. For this reason, we need to run a migration to purge security_scans
associated with security_findings
without finding_data
.
We could also try to set the finding_data
attribute of the security_findings
records but that would require a really complex data migration.
Implementation plan
-
database Create a background migration to purge the security_scans
records associated withsecurity_findings
withoutfinding_data
.
Verification steps
- Install the GitLab version
15.5
- Run a security build on that instance to create
security_findings
records - Make sure there is no
finding_data
column for thesecurity_findings
table - Upgrade the GitLab version to the current and run the migrations
- Check the already existing
security_scans
records and make sure they are purged.
You can also create a GitLab instance by using: https://handbook.gitlab.com/handbook/infrastructure-standards/realms/sandbox/#how-to-create-a-terraform-environment