Follow-up from "Simplify Gcs::Converter.convert"
The following discussion from gitlab-org/security-products/analyzers/container-scanning!2570 (merged) should be addressed:
-
@zmartins started a discussion: (+1 comment) This and the following changes are raising an important message. They are showing us that we are getting into a mix of responsibilities that we might need to address soon (?):
-
Gcs::Convert
only concern should be to convert the output file from the analyzer into a single format where we can output both as a table and report file. So it could be seen as a post processing mechanism for the overall scanned/vulnerability data and therefore it should keep only the data required throughout the conversion process (it has never stored vulnerabilities for example). -
Although we have
Gcs::Remediation
already as an encapsulated entity, it seems that we might need something likeGcs::Remediations
which would handle values and behaviours specific to the group ofGcs::Remediation
(e.g., unsupported os info, checking for duplication, checking for applicability). -
With the previous points we would have a cleaner and more cohesive version of
Gcs::Convert
and a place of isolation to increase our test coverage in regards to the remediation.
@sashi_kumar I was wondering WDYT about this?
🤔
Feel free to tell me I am building castles in the sky. -
Implementation Plan
-
backend Create a new class named Gcs::Remediations::Collection
which represents a collection of remediations. -
backend Inside Gcs::Convert
, create a new collection. Add a new remediation to the collection for each vulnerability -
backend Move the logic related to remediations out of Gcs::Convert
and intoGcs::Remediations::Collection