Support fallback events in the report module
What does this MR do?
Sometimes we have multiple, distinct components that manipulate the gitlab report.
Previously the report module strictly enforced observability events to be registered which basically required the addition of event types directly to the report module to make sure that all consumers are aware of all events. Central event registration is required so that the analyzers (consumer) and post-processor (tracking-calculator) correctly consume and produce reports.
This design is not very modular; it does not support the development and integration of events on the consumer's side. This review comment summarizes the core problem with this design.
This MR integrates a fallback-event which we use to preserve the raw data with a MarshalJSON method that enables us to reconstruct the original JSON so that obervability events can be consumed and produced without a need for central registration.
Experimental Semgrep integration: Draft: Bump report module + fallback event (semgrep!680) • Julian Thome • 18.6
What are the relevant issue numbers?
Does this MR meet the acceptance criteria?
-
Changelog entry added -
Documentation created/updated for GitLab EE, if necessary -
Documentation created/updated for this project, if necessary -
Documentation reviewed by technical writer or follow-up review issue created -
Tests added for this feature/bug -
Job definition updated, if necessary -
Ensure the report version matches the equivalent schema version -
Conforms to the code review guidelines -
Conforms to the Go guidelines -
Security reports checked/validated by reviewer