Full Code Quality Report
Problem to solve
GitLab Code Quality runs on code and creates a report that is then shown in the MR widget as the changes (+/-) related to that specific branch. The current functionality provides great insights about how a merge request would changed the code quality of the target branch. This is limiting to Sasha who may want to increase quality of the project for any number of reasons but cannot see the code quality report easily to iterate.
Intended users
- Sasha (Software Developer)
- A QE or SDET may also make use of this to solve the same problems Sasha has.
Further details
Use Cases
Sasha:
- When I want to increase the code quality of a project, I need a full report of current code quality, so that I can quickly identify code that can be improved in quality AND deliver value to customers.
QE/SDET:
- When I am looking for areas to test, I want a report of code quality deficiencies, so that I can write tests to find/fix software that will hinder value delivery to customers.
Proposal
If a codequality job is defined the full code quality report should be made available in the Job view in the same place the security report is today.
If the report contents cannot be rendered in a way that makes sense to users and is actionable or it takes excessively long to load (10 seconds+) the feature will not be useful in driving the outcomes they want.
Some considerations here would be:
- Pagination for the issues if > 25
- A link to the file in question as is shown in the MR widget
- Text of the error as is shown in the MR widget
-
Stretch: Making the report contents sortable on the remediation points value. By default sort descending (lowest values at top).A new issue (#209795 (closed)) was created to track this enhancement. - Only the most recent code quality report will be displayed. Users can retrieve reports from previous pipelines from the artifact browser there.
- If no report exists to render due to expiration show a message indicating why the full report is missing.
Permissions and Security
Existing permissions apply.
Documentation
- Update the Code Quality documentation to reference the new capabilities.
Testing
What does success look like, and how can we measure that?
Acceptance Criteria
- Report view gets reviewed by UX (mobile view is a stretch goal)
- Report can be rendered in under 10 seconds on tab load
- Report is sorted by remediation points descending on load
- Report can still be downloaded
What is the type of buyer?
The Buyer of this functionality is the QE Manager, Development Team Lead or Engineering Leadership.
Links / references
/label feature