Skip to content

Draft: Soften Vulnerability Resolution messages, explain next steps

Connor Gilbert requested to merge connorgilbert/vr-dont-be-so-negative! into master

What does this MR do and why?

  1. Edit the text for the MRs and suggestions that Vulnerability Resolution creates.

    • Goal: Reduce SHOUTING and **be very careful!**-type messages that, in my opinion, make the feature seem dangerous and stressful to use.

    • Instead, more clearly explain what someone should specifically do to exercise an appropriate level of caution: for example, they should verify that the fix doesn't break functionality and does fix the vuln.

    • This is similar in spirit to the documentation changes in !167983 (diffs), which, among other things, changed:

      We cannot guarantee that the large language model produces results that are correct. Use the explanation with caution.

      to

      We can't guarantee that the large language model produces correct results. You should always review the proposed change before merging it. When reviewing, check that:

      • Your application's existing functionality is preserved.
      • The vulnerability is resolved in accordance with your organization's standards.
  2. Reformat MRs to more clearly explain what is happening in the long MR description.
  3. Change the text used in VR-in-the-MR comments to more clearly separate (1.) the user, (2.) GitLab, (3.) the AI feature. Currently, the comment is posted under an individual user's name, but it just jumps right into "The suggested code changes were generated by GitLab Duo..." (oddly passive), then directs someone (the MR author?) to "Use this feature with caution", then shifts to "our documentation" (meaning GitLab's, not the user's!).

References

Please include cross links to any resources that are relevant to this MR This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Edited by Connor Gilbert

Merge request reports