Ericsson / codechecker

CodeChecker is an analyzer tooling, defect database and viewer extension for the Clang Static Analyzer and Clang Tidy
https://codechecker.readthedocs.io
Apache License 2.0
2.15k stars 357 forks source link

[doc] Update the GitLab CI integration guide #4234

Open mcserep opened 2 months ago

mcserep commented 2 months ago

There is an issue with the CodeChecker integration into GitLab CI as a Code Quality tool, which this PR aims to fix. I have possible 2 solutions. This PR provides the fix for the 1. solution, as the suggested one.

  1. The built-in code quality template jobs - depending on CodeClimate - succeed in case issues were found, and the results are made available usually as a general artifact (downloadable JSON, XML file) and also as a special report artifact, which is used by GitLab to visually display the issues, both at the pipeline and at MRs. This is also the usual workflow of GitHub's approach with CodeQL by the way: code quality CI jobs fail only in case of execution error and not because of found code quality issues.

    The current guide of the CodeChecker integration does not follow this pattern, as it fails the CI job in case any issues in the code was found. I think this will usually not be expected by developers, and instead the convention should be followed.

  2. Even if you think otherwise, the current guide needs to updated. By default GitLab CI will only upload artifacts upon job successfulness, see the reference: artifacts:when. This means that with the current configuration the code quality job will fail in case any issues were reported and then the artifact (gl-code-quality-report.json) will not be uploaded to the GitLab server. Note: the special report artifact will be uploaded though and visualized by GitLab, but not as "normal" JSON file artifact, and therefore it won't be downloadable when required. (As stated at the above link: "The artifacts created for artifacts:reports are always uploaded, regardless of the job results (success or failure).")

    This could be fixed by adding a when: on_failure or a when: always configuration for the artifact.