Skip to content

Refactor code quality similar to JUnit tests

Problem

In order to reliably implement https://gitlab.com/gitlab-org/gitlab-ee/issues/2526 we need to refactor code quality to be similar to Junit tests and inside of Test summary

  1. We want to user existing mechanisms for exposing JUnit test results here, because it would abstract test notices / reports in a clean and maintainable way.

  2. Currently we expose raw code quality notices, and we want to pull this into the same abstraction that we have built for JUnit test reports

  3. These two things are very similar conceptually and having unified implementation that handles both can make it much easier to extend these features in the future.

  4. we would likely introduce: reports: codequality: codequality.json as additional report type

  5. Code Quality would fall under separate section / scope: Code Quality

Implementation

  1. Extend .gitlab-ci.yml with reports: codequality: codequality.json
  2. Allow downloading reports from ArtifactsController#download likely with ?file_type=codequality
  3. Extend https://gitlab.com/gitlab-org/gitlab-ee/blob/master/ee/app/serializers/ee/merge_request_widget_entity.rb#L20 to support a new reports: codequality: codequality.json syntax where we download individual report file using artifacts#download
  4. The codequality: report will be sent as gzip file, similar to what we do today with JUnit

Intent

  1. We just improve syntax
  2. We just send the codequality report as .gzip
  3. We do not implement parsers yet (we don't need them at this moment)
  4. We do not change frontend (we return a raw file from new reports:, and frontend does comparison as today)

Limitations

Since we don't parse data on Backend this would still be limited to a single codequality.json file, as it is happening today. Now we rely on a single codequality job so it has the same implications.

People might think that they can add multiple jobs with reports: codequality: codequality.json, but this will not work. We might consider raising an error when such case is discovered.

Deprecation

Once we do that, we can replicate the same behavior to all other security products reports. We should deprecate the usage of job level codequality and document the usage of reports: codequality:. We should remove the old way of dealing with that in %12.0.

Edited by Matija Čupić