Remove usage of `message` field in Vulnerabilities
Why are we doing this work?
With Deprecate and stop processing `message` field i... (#411573 - closed) we will have stopped processing the message
attribute from both CI pipelines and GraphQL mutations. In order to prepare for dropping the column we should ignore the message
column and make necessary adjustments
Implementation plan
- Mark the
message
column as ignored according to database guidelines - Make necessary adjustments in the code base, a non-exhaustive list of places:
-
ee/app/services/vulnerabilities/create_service_base.rb
-
ee/app/services/vulnerabilities/manually_create_service.rb
-
ee/app/services/vulnerabilities/starboard_vulnerability_create_service.rb
-
ee/app/services/vulnerability_exports/exporters/csv_service.rb
-
ee/app/graphql/mutations/vulnerabilities/create.rb
-
ee/app/graphql/types/vulnerability_type.rb
-
ee/app/models/ee/vulnerability.rb
-
ee/app/models/vulnerabilities/finding.rb
-
lib/gitlab/ci/parsers/security/common.rb
-
lib/gitlab/ci/reports/security/finding.rb
-
ee/app/services/security/ingestion/**
- Adjust specs
Verification steps
- Trigger a pipeline using a report that contains a vulnerability with a
message
property with a value different to thename
. (example) - Go to the pipeline security report and confirm that the vulnerability name matches the
name
property, notmessage
. - As above, for the vulnerability report.
- As above, for the GraphQL query (instead of
name
, thetitle
must match) - In the vulnerability report, click export. In the generated CSV, the
Vulnerability
column must matchname
. TheAdditional Info
column must be empty.
Edited by Thiago Figueiró