Skip to content

Use issue_links instead of issue_feedback on pipeline security tab

What does this MR do and why?

As part of the vulnerability feedback deprecation, we are switching from using the issue_feedback property in the finding to the issue_links property. This MR does the switch for the findings in the pipeline security tab. The property is used to control whether the "Create issue" button is shown in both the finding list and modal, and the issue note in the modal if there's a created issue:

Old property vs new Create issue button in list Create issue button in modal Issue note
ksnip_20230313-160837 ksnip_20230313-160922 ksnip_20230313-160955 ksnip_20230313-161005

How to set up and validate locally

  1. This is behind the feature flag deprecate_vulnerabilities_feedback, but don't enable it yet.
  2. Clone https://gitlab.com/svedova/test-remediations-v2 and run a pipeline against the main branch.
  3. Go to the pipeline's security tab. You should see 2 vulnerabilities. Click on one of them to open the modal.
  4. This is where it gets a bit tricky. Both the old and new properties are in the finding and they mirror each other, so doing something to one will also update the other. This means that the code could be using the wrong property but still work. The best way I can think of to verify that the correct property is being used, is to manually modify the property and see if the UI responds:

Feature flag off, create issue button in list

Feature flag off, create issue in modal

Feature flag on

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #390072 (closed)

Edited by Daniel Tian

Merge request reports

Loading