Show a file has codequality data on MR diff view
When you are reviewing a Merge Request and see there are Code Quality violations introduced you may want to help the author by pointing out how they can resolve those. Today this involves having multiple windows open to see the violations on the Merge Request summary and another reviewing the changes in the MR or your IDE. After going back and forth trying to find what the problem is you give up and just go back to reviewing the change but ignoring those new violations.
Now you can see right in the Merge Request diff view if the file you are reviewing has new code quality violations that are part of this change. This gives you the context to suggest a fix as part of your normal workflow within GitLab without having to keep more windows open and context switch back and forth between them.
Problem to solve
As a code reviewer, I want to see on the Changes tab of an MR if a modified file has code quality violations, so I can click back to the CQ MR widget only when needed and stay focused on improving the quality of this change.
- Sasha (Software Developer) - Who is doing a code review on another developer's MR and wants to see how new code quality violations impact the overall project.
User experience goal
The user should be able to see in the MR Diff view if one of the files modified in this merge request has a changed code quality violation.
- If a file in the MR Diff view has a code quality entry in the MR Widget add a badge with some helper text of "The merge request has been updated, and the number of code quality violations in this file changed."
- Link the badge so it navigates to the merge request main page widget in a single click OR open that modal on this page. Dev to decide which is lower LOE and implement.
This is an iteration towards showing the notices inline and is short term / will be removed when that is done.
Permissions and Security
- Add to the existing documentation page that Code Quality notifications now appear on the Changes tab of a Merge Request. Doesn't need to include a screenshot until we have the fully rolled out feature.
Availability & Testing
What does success look like, and how can we measure that?
- Documentation is written about what needs to be uploaded on source/target branch pipelines to invoke the feature
- Barebones documentation about the feature is in place to reduce deletions when full feature is present
- When a source file has a new or resolved code quality violation there is a badge/treatment about that on the MR Diff View
Measures of success
- None for this - full measures of success of this feature are noted in #2526 (closed)
What is the type of buyer?
Dakota (application developer director) and Alex (application development Manager) who want teams to reduce tech debt know this feature enables them to get context of violations as part of an existing workflow.
Is this a cross-stage feature?
Yes. This crosses over withwho has been in the loop on the proposed change.