Skip to content

Use the security dashboard vue app in the security tab on the pipelines page

Problem to solve

We need to Move Security reports logic to the backend. We originally planned to do this by refactoring the <split-security-reports-app/>, but it would be a lot quicker, easier, and nicer to port the dashboard over instead and completely replace the <split-security-reports-app/> as (crudely) depicted in the screenshot below.

Security pipeline dashboard

Intended users

Further details

The endpoint for this was already created in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14376 we just need to pull the group security dashboard over and get it to use the new endpoint (in theory). You can see how it was used in this WIP MR !14887 (closed)

There are a few caveats to doing this:

  1. The "total" number of reports will need to be added to the tab. This can be found in the X-Total header of the API endpoint.
  2. We need to only show the list and vulnerability management part of the dashboard. We need to make sure the graph and "counts" don't get shown.
  3. I'm not 100% sure what filters we can and can't use. If they get tricky, remove them and add them back in in a further iteration.

Permissions and Security

Not sure if this is the right section for this, but we should put this behind a feature flag. Previously the plan was to add separate feature flags for each report. However, this is now an all-or-nothing approach so we should consider changing this and having a single pipelineReportApi feature flag (relevant feature flag discussion).

Documentation

This will require a documentation change as the reports will change fairly dramatically. We'll need to update all screenshots and write-ups for the reports documentation and potentially add this to the list of dashboards on the Security Dashboards section.

See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements

Testing

This is a perfect opportunity to test the speed changes of this approach. If they have a negative impact, that's something we really want to address before using this same approach on the MR page.

What does success look like, and how can we measure that?

Success will be having the dashboard list in the security tab and finally having the pipeline reports logic full in the back end. We may be able to measure that by checking the API calls to the newer endpoint, but I'm not sure this is either necessary or reliable.

Links / references

Checklist:

  • UX Evaluate proposed changes.
    • Suggest adjustments if necessary
  • Account for edge cases and empty states
  • Frontend !15682 (merged)
  • Enable feature flag by default !15824 (merged)
  • Docs gitlab-ce!32396
Edited by Mark Florian