SonarCloud analysus stopped digesting Code Coverage report

SonarCloud
, , , ,
1

For our dotnet application we use SonarCloud as analysis in Azure DevOps, this is working well but since the 24th of February we have noticed that no code coverage reports have been digested by SonarCloud. We have not changed anything in our build.yml since days before that happened and code coverage is also still reported on the build summary itself.

The steps we use to generate the data is as follows:

- task: SonarCloudPrepare@1
  displayName: 'Prepare analysis configuration'
  inputs:
    SonarCloud: 'SC'
    organization: 'organization'
    scannerMode: 'MSBuild'
    projectKey: 'organization.project'
    projectName: 'organization.project'

- task: DotNetCoreCLI@2
  displayName: 'Build solution'
  inputs:
    command: 'build'
    projects: '**/*.sln'

- task: DotNetCoreCLI@2
  displayName: 'Execute Unit tests'
  inputs:
    command: 'test'
    projects: '**/*.csproj'
    arguments: '--collect "Code Coverage"'

- task: SonarCloudAnalyze@1
  displayName: 'Run SonarCloud analysis'

- task: DotNetCoreCLI@2
  inputs:
    command: 'publish'
    publishWebProjects: false
    projects: '**/*.Functions.csproj'
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'

- task: SonarCloudPublish@1
  displayName: 'Publish results on build summary'
  inputs:
    pollingTimeoutSec: '300'

I have attached the log for the analysis step,
sonarlog.txt (199.7 KB)

2

Hey there.

It looks like coverage reports are still being produced/parsed by the analyzer, but no main files are being found to report coverage on.

2022-03-01T13:43:16.1256129Z INFO: Coverage Report Statistics: 48 files, 0 main files, 0 main files with coverage, 48 test files, 0 project excluded files, 0 other language files.
2022-03-01T13:43:16.1257147Z WARN: The Code Coverage report doesn't contain any coverage data for the included files. Troubleshooting guide: https://community.sonarsource.com/t/37151

What this might mean is that something has changed in one of your other projects that messes with the Detection of Test vs. Product projects.

I see a few projects in your logs with indexed test sources that don’t immediately look like test projects (only you’ll know)

For example:

2022-03-01T13:43:00.4218905Z INFO: Indexing files of module 'ProjectOverview.Application'
2022-03-01T13:43:00.4219807Z INFO:   Base dir: D:\a\1\s\src\ProjectOverview\ProjectOverview.Application
2022-03-01T13:43:00.4221012Z INFO:   Test paths: ApplicationServiceExtensions.cs, AssemblyInfo.cs, Projects/Quer...
2022-03-01T13:43:00.4222235Z INFO:   Excluded sources: **/build-wrapper-dump.json
2022-03-01T13:43:00.4222780Z INFO:   Excluded sources for coverage: **/Migrations/*

(the clear indicator is by the existence of Test paths: in the logs)

I would recommend having a look at the aforementioned wiki page and checking that your projects are being categorized correctly. Something could have changed in a .csproj file (different project type GUID, a test dependency added) that’s messing with the categorization. You wouldn’t see this change in the build.yml file, rather the project file.

5

Hmm interesting.

That definitely aren’t test projects, I do however have an [assembly:InternalsVisibleTo(“testassembly”)] in the assemblyinfo files which it seems to point towards too, but we have had that for weeks without issues…

6

Found the most likely issue.

Moq was accidentally added as a reference to a common project used by all other projects. I know do get some results back in SonarCloud though it still looks a bit weird with seeing only one line with missing coverage, but it’s more then earlier.

7

Hmm seems this wasn’t the only issue. looking into a log of a fresh log I can see that according to the analyzer the following file is a test path: line 178: INFO: Test paths: Abstractions/Repositories/IIndexRepository.cs, Abstractions/Rep...

This is the content of the file:

namespace ProjectOverview.Domain.Abstractions.Repositories;

public interface IIndexRepository<in TIndex>
{
    // ReSharper disable once InconsistentNaming
    Task CreateIndexAsync(TIndex index, CancellationToken cancellationToken);
}

There is nothing in that file that looks like test code or assembly references to me.

log:
10.txt (273.8 KB)

9

Hi @DdeM,

The categorization is done on the project level. All files of your ProjectOverview.Domain project are categorized as Test Source. You can check your build log to see why the project was categorized as Test Project.

From your log:

2022-03-03T14:16:00.5679034Z INFO: Indexing files of module 'ProjectOverview.Domain'
2022-03-03T14:16:00.5686291Z INFO:   Base dir: D:\a\1\s\src\ProjectOverview\ProjectOverview.Domain
2022-03-03T14:16:00.5687659Z INFO:   Test paths: Abstractions/Repositories/IIndexRepository.cs, Abstractions/Rep...
10

Seems the Moq reference snuck in via another way, so that is why it showed the whole project as a test project.

Basically ProjectOverview.Domain → Common → Moq creates the issue. If possible it could be nice to have something more specific about this in the log/

11

@DdeM there is more information in the build log:

image
image953×136 6.62 KB

We can’t easily tell whether the reference to the test assembly is direct or indirect (as in your case), but it still gives a pretty good idea of the root cause.

See this section on the page @Colin referred to for more information.