Coverage configuration

Guys!

We have a problem configuring coverage for an internal project, I set the coverage to be 65%, so we started to have problems that SonarCloud refused a Pull Request but validation does not occur in PR’s changed code, it denies the PR by another part of the code that will not be part of the merge.

I would like to better understand why this happens and how we can improve this process.

I emphasize that the total coverage of the project is 59% and is below the metric for PR.

Hi @Kaique_Goncalves, welcome to the community forum.

The coverage on PRs should be computed on the new code only.
Having a coverage threshold on PRs greater than the project overall coverage percentage, like you did, is very good practice to improve gradually.

Did you set the quality gate condition on coverage on “New Code”, not on “Overall Code”? That would explain why the PR analysis is failing on uncovered code that is not on the PR.

coverage_on_new_code

HTH,
Claire

Hi Claire,

The configuration I made was exactly that for “New codes”, will the error not be related to the total Coverage of the project, which was smaller than the “new codes”.

The condition configuration seems fine.

When you analyze a PR, on the “Code” tab, do you see only the files changed on the PR, or all the files of the project?
You should see only the changed files. If you see all the files, it means the detections of the changed files during the Sonar Scanner execution has failed. Very often, it’s because the .git directory is not accessible to the scanner during its execution, or because the project is cloned without the full history.

How do I validate and guarantee that this configuration will always be ok not to generate new problems?

Hi @Kaique_Goncalves

I don’t understand your question. Is the original problem solved? What part of the configuration would you like to validate, or do you expect to generate problems in the future?