It seems like SonarCloud started assessing the full coverage instead of just the PR related coverage

Since earlier this week our SonarCloud started failing for all PRs and showing the results of what would be our main branch (where the coverage is below the threshold) but either the PRs are not touching code or are covering with Unit Tests, but it is still failing and showing coverage for unrelated files.

Anyone else facing the same issue?

Sonar folks, does anything changed recently that could have caused this?


I see the Sonar Scanner image we use just got updated Releases · SonarSource/sonarcloud-github-action · GitHub not sure it is related.

Update 2

I discarded the hypothesis of a change in the Scanner. Going back a few weeks I see we changed the actions/checkout parameter fetch-depth: 0 and then I got to realize the warnings about shallow copy in the SonarCloud UI.

I have now rollback to use fetch-depth: 0 but that moves my checkout step from 10 seconds to 10 minutes, I know I can do some pruning on the repository to reduce that time, but still I would like if there is guidance or documentation on what exactly I need to have in place in order for the scanner to work properly?

Does the last commit of the current branch + the PR head commit suffice the requirements? Have anyone done a setup that checks out the minimum necessary for the scanner to run successfully?



I’ve asked for documentation improvements around this, but at the moment all I can tell you is fetch-depth: 0.


1 Like

Thank you @ganncamp, even though documentation is not yet improved would someone be able to give a gist of what is used in the analysis? Is it the head commit in the head branch + head commit in the current branch?

Also for some reason, my project has not “healed”, even though I am now using fetch-depth: 0 many branches are failing Unit Test coverage while the code is actually covered. Is there any cache that could be impacting this?


No. We don’t cache this data. We read your coverage reports fresh each time.