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 with security_findings without finding_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 the security_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

Edited by Mehmet Emin INAC