Draft:[PoC]: Set the initial structure to load vulnerabilities async
What does this MR do and why?
Set the initial structure to load vulnerabilities async. This change is required in order to have the frontend code supporting both project and group level.
Note that the approach above would provide enough support that adding vulnerabilities for group level dependencies wouldn't require many changes.
~In the backend, it changes the vulnerabilities payload from [{id: 1, name: 'name', severity: 'unknown', url: 'http://gdk.test:3000/top-group/project-2/-/security/vulnerabilities/1141'},...]
to [1,...]
. It also adds the column highest_severity
in order to keep supporting the sort by severity feature.
In the frontend, it updates the shared (project and group level) code to support the new format. The information that was previously preloaded is fetched via an async request.
Pros
- As we add vulnerability data into dependency, this approach will avoid increasing the amount of data being fetched as part of
dependencies.json
. - It doesn't add too much complexity to the frontend.
Cons
- Users will experience additional loading (see screenshot).
Screenshots or screen recordings
Ingestion comparison (only for comparison)
Hash(MR) | Integer(i.e. this MR) |
---|---|
Query plan link | Query plan link |
Time: 55.838 ms | Time: 43.528 ms |
hits: 533 (~4.20 MiB) from the buffer pool | hits: 532 (~4.20 MiB) from the buffer pool |
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.