Remove `.ordered` scope from sbom-to-vulnerability ingestion mapping
What does this MR do and why?
During review for MR 160015, it was mentioned that removing the ordering by severity could simplify the database query.
It doesn't appear that order is explicitly required for this code. The tests were relying on the order, but it appears that was just taking advantage of the order for testing convenience, not because it is a product requirement
There was some further discussion in this thread that also indicates the order can be removed.
I split this out to a separate MR as Update `ingest_occurrences_spec` to use real fi... (!160015 - merged) • Michael Becker • 17.4 is not really near a merge-able state
SQL
Old
SELECT
"vulnerability_occurrences".*
FROM
"vulnerability_occurrences"
INNER JOIN "vulnerability_occurrence_pipelines" ON "vulnerability_occurrences"."id" = "vulnerability_occurrence_pipelines"."occurrence_id"
WHERE
"vulnerability_occurrence_pipelines"."pipeline_id" = 1376275301
AND "vulnerability_occurrences"."report_type" IN (2, 1)
ORDER BY
"vulnerability_occurrences"."severity" DESC,
"vulnerability_occurrences"."id" ASC;
https://console.postgres.ai/gitlab/gitlab-production-main/sessions/30202/commands/93803
New
SELECT
"vulnerability_occurrences".*
FROM
"vulnerability_occurrences"
INNER JOIN "vulnerability_occurrence_pipelines" ON "vulnerability_occurrences"."id" = "vulnerability_occurrence_pipelines"."occurrence_id"
WHERE
"vulnerability_occurrence_pipelines"."pipeline_id" = 1376275301
AND "vulnerability_occurrences"."report_type" IN (2, 1)
https://console.postgres.ai/gitlab/gitlab-production-main/sessions/30202/commands/93804
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Related to #472760 (closed)