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
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.
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
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.
we would likely introduce:
reports: codequality: codequality.json
as additional report typeCode Quality would fall under separate section / scope:
Code Quality
Implementation
- Extend
.gitlab-ci.yml
withreports: codequality: codequality.json
- Allow downloading reports from
ArtifactsController#download
likely with?file_type=codequality
- 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 usingartifacts#download
- The
codequality:
report will be sent asgzip
file, similar to what we do today with JUnit
Intent
- We just improve syntax
- We just send the codequality report as
.gzip
- We do not implement parsers yet (we don't need them at this moment)
- 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.