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.
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.
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:25.5960169Z 659F3AF4-4E8E-4025-A920-0A2644950B06.sonar.sources=\
2023-10-02T13:27:25.5960597Z "D:\\agent\\682\\s\\a\\b\\c.cs",\
...
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:04.1322869Z D:\agent\682\s\a\b\c.cs
...
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:
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 (/ vs \). You see, \ is an escape character in Java, which is the underlying engine here.
E.G.:
The \ 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 \\.
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.