- ALM used : Azure DevOps
- CI system used: Azure DevOps
- Languages of the repository: typescript, c#, sql
- Scanner: .NET
We use sonarcloud monorepo, so this is a repository with two sonarcloud projects (A and B) with shared files. Monorepo might not be related, but I’m mentioning anyway as this does make things more complex usually.
In a PR, triggering analysis for both projects, one of them is displaying no coverage for a new file exclusive to that project.
The coverage report (generic format) does contain data about such file, path is correct and matches what is seen in sonar.sources in analysis log.
We are sure the report is sent/consumed by Sonarcloud because another pre-existing changed file shows coverage correctly.
No problems were noticed in the other monorepo project linked to the same repository.
Can you provide the analysis log?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
This guide will help you find them.
I’m working on the redacted version of the log.
While doing that I noticed this section:
2023-09-28T18:26:05.4288502Z 20:26:05.428 INFO: Sensor Generic Coverage Report
2023-09-28T18:26:05.4291233Z 20:26:05.428 INFO: Parsing X:\_temp\CodeCoverage\Merged\SonarQube.xml
2023-09-28T18:26:05.7074136Z 20:26:05.706 INFO: Imported coverage data for 477 files
2023-09-28T18:26:05.7074672Z 20:26:05.706 INFO: Coverage data ignored for 1005 unknown files, including:
2023-09-28T18:26:05.7078190Z 20:26:05.706 INFO: Sensor Generic Coverage Report (done) | time=278ms
It mentions just 5 files, is there a way to get the whole list of files?
I’m already using verbose mode as in the begining I can read:
20:25:29.153 sonar.verbose=true was specified - setting the log verbosity to 'Debug'
It looks like you’re already getting debug-level logs, so you probably won’t be able to get the full list of files.
Nonetheless, this is likely the root cause of the problem in your OP.
What, exactly, is the problem? The paths in your report don’t match the paths analysis is seeing. Figure out the fix for the first five files and that’ll likely be the fix for the rest.
I’m trying to get that number down, the first half was easy, just frontend files not actually referenced by a Visual Studio project, that’s why Sonarcloud didn’t know about them. But this issue is about a c# one, so VS and Sonar know about it.
It didn’t yet popped up on the 5 reported by the sensor, but I already got stuck on the first one, these are all the references of such file (c.cs)
2023-10-02T13:27:25.4680833Z 15:27:25.453 Using TFS/Azure DevOps sources directory as project base directory: 'D:\agent\682\s'.
2023-10-02T13:27:36.1347989Z 15:27:36.133 DEBUG: Source paths: c.cs, ...
2023-10-02T13:27:36.1359239Z 15:27:36.134 DEBUG: 'a/b/c.cs' generated metadata with charset 'UTF-8'
2023-10-02T13:27:36.1360998Z 15:27:36.135 DEBUG: 'a\b\c.cs' indexed with language 'cs'
2023-10-02T13:28:04.1322373Z 15:28:04.131 INFO: Coverage data ignored for 558 unknown files, including:
2023-10-02T13:28:09.4883317Z 15:28:09.487 DEBUG: Not enough content in 'a/b/c.cs' to have CPD blocks, it will not be part of the duplication detection
2023-10-02T13:28:12.0859194Z 15:28:12.085 DEBUG: Incremental PR analysis: Adding hash for 'a/b/c.cs' to the cache.
And this is how it appears in the coverage file, it is the very first file on the coverage report:
<lineToCover lineNumber="6" covered="false" />
<lineToCover lineNumber="7" covered="false" />
<lineToCover lineNumber="8" covered="false" />
I can’t see why
With (understandably) obfuscated paths, I’m not going to be able to diagnose this for you. I can only re-iterate that the paths analysis is seeing don’t match the paths in the report. If, as indicated by your replacements, they really do match, segment to segment, then this may be a question of path separators (
\). You see,
\ is an escape character in Java, which is the underlying engine here.
\ on the first line is being used to escape the newline. Then each
\ in the path is escaped with a preceding
\ for path separators of
It was case sensitivity issue.
Folder containing the C# project was named Project in file system, but the solution file was referencing to it as PRoject, everything else was working fine (using Windows here) but that cause Sonarcloud to do not find the files, even though we’re building in Windows as well.
That also explain why some files worked and others don’t, not all projects had that case problem.
Some parts of Sonar did find the file, it seems to only be a problem to the coverage sensor.