Skip to content

Simplify code quality for docs config

Marcel Amirault requested to merge run-code-quality-changed-docs-only into master

What does this MR do and why?

The code quality job for docs warnings runs on all files every time. We can reuse the logic from the lint-doc.sh script to only report on warnings from the changed files.

Some issues this hopes to resolve:

  • The code quality widget in MRs sometimes takes ages to load, or never finished loading. This might be due to the docs artifact being very large with 9k+ warnings.
  • The diff annotations (the key reason we are using this) that shows warnings in the diff sometimes didn't show up. We suspected it was also due to the large number of warnings, with warnings near the top of the list showing up, and warnings near the bottom often failing to load.

After chatting with @rossfuhrman from groupstatic analysis, we decided it'd be best to simply run it in MRs, and only for changed files. We'll skip running it in master, so it does not interfere with the regular code quality artifact in the latest pipelines on master.

This MR:

  • Copies and simplifies the code from lint-doc.sh so that we only report on the files changed in the MR. (the extra logic from the other script isn't needed here).
  • Sets the job to allow_failure: true (instead of || exit_code=$? in the job script), if there are failures in the job.
  • Sets the job to run only for MRs, and run the new script.

I tested it by adding a docs change with a few warnings and errors, tested in this pipeline: https://gitlab.com/gitlab-org/gitlab/-/pipelines/703875566

Then I dropped the commit, and this MR is ready for review.

Related to #378718 (closed)

Screenshots or screen recordings

This screenshot is from this MR when the test commit adding warnings/errors to docs was present (now removed to be ready for merge):

  • Screenshot_2022-11-24_at_15.40.08

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