Skip to content

Run code quality in all docs and code MRs

Marcel Amirault requested to merge update-docs-code-quality-job into master

What does this MR do and why?

This MR mostly reverts the changes made in !104924 (merged) and brings us back to outputting the full code quality report for docs warnings again. Due to some performance and UI issues at that time, we added a script that made the report only include warnings for changed files. We no longer need to do this and can run on all docs again, due to a couple reasons:

  • Since the previous MR, there have been several fixes to code quality UI so that we should be able to use the full report. These fixes include:

  • We also trimmed the total number of warnings in the docs by dropping some rules down to suggestion level (which do not appear in the report) in !106850 (merged). This pruned about ~4k-5k warnings, so the artifact is now down to ~2mb, from 3.1mb+ previously. Again, this should help any lingering performance questions.

  • Finally, in January we'll have a docs-only hackathon that will focus on cleaning up many of these docs warnings. We've added a label that shows when warnings are resolved by the MR in #374631 (closed). This will be great visual feedback for our contributors, to see directly in the widget a message that essentially says "This MR has correctly resolved X (docs) code quality warnings". To make this work, we need to have the report artifact in master pipelines to compare against, to know which issues have been resolved.

As part of this, we should be sure to always run the docs code quality whenever we run the regular code quality (and vice versa), so that we are always comparing against the full list of results. If we don't keep the regular code quality report in docs pipelines, for example, GitLab will think "Oh, all code warnings have been resolved!" and will say that in the MR report widget. Similarly, in code MRs, it'll think all the docs warnings are resolved if the docs report artifact is missing.

Screenshots or screen recordings

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

How to set up and validate locally

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

MR acceptance checklist

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

Edited by Marcel Amirault

Merge request reports