SonarCloud code coverage remains 0.0 in GitHub Actions build

Question

I have setup CI for a .NET Core solution using GitHub Actions. When code is pushed to the master branche, the solution is build, the unit tests are run and code analysis is run with SonarCloud. The code analysis step is actually performed by sonarcloud-github-action.

The quality gate in SonarCloud does not pass because the coverage percentage is 0.0% (for both new as existing code). I'm generating code coverage reports using Coverlet. The coverage.opencover.xml file is succesfully generated after test execution for each unit test project. In the sonar-project.properties file I'm referencing these files as follows:

sonar.cs.opencover.reportsPaths=**\coverage.opencover.xml

But apparently the code coverage reports are recognized but not processed by the SonarCloud scanner. In the log of my GitHub Actions workflow, I do see these warnings:

INFO: Parsing the OpenCover report <path>/coverage.opencover.xml INFO: Adding this code coverage report to the cache for later reuse: <path>/coverage.opencover.xml ... WARN: Missing blame information for the following files: WARN: * <path>/coverage.opencover.xml WARN: This may lead to missing/broken features in SonarQube

In trying to solve the 'Missing blame information' warning, I added the coverage files to the exclusions in my SonarCloud project: **/coverage.opencover.xml but that didn't solve the issue. The warning still appears and code coverage is still 0.0%.

Any hints to get this going?

[edit]:

My workflow in GitHub Actions looks like this:

name: .NET Core
on: [push]

jobs:
  build:

runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v1
- name: Setup .NET Core
  uses: actions/setup-dotnet@v1
  with:
    dotnet-version: 2.2.108
- name: Build with dotnet
  run: dotnet build src/<solution>.sln --configuration Release
- name: Unit Tests
  run: dotnet test src/<solution>.sln /p:CollectCoverage=true /p:CoverletOutputFormat=opencover
- name: SonarCloud Scan
  uses: sonarsource/sonarcloud-github-action@master
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

`

It’s difficult to help without seeing your workflow. Please add it to your question if you can. The filesystem is preserved between steps but not jobs, so make sure both actions run in the same job. — peterevans, Nov 15 '19 at 09:50

score 4 · Answer 1 · answered Nov 29 '19 at 08:33

I had a similar problem getting the coverage of a Typescript project to work. Without your sonar logs I just can guess but the problem was that the paths inside the lcov.info where absolute path from github something like SF:/home/runner/work/YoutRepoName.. and Sonar was starting a Docker container and set the workdir to /github/workdir and therefore could not locate the files from the lcov.info.

Check your logs if you find something like

2019-11-28T15:36:34.9243068Z WARN: Could not resolve 2 file paths in [/github/workspace/test/unit/coverage/lcov.info], first unresolved path: /home/runner/work/jobreporter/jobreporter/dispatcher/index.ts
2019-11-28T15:36:34.9243445Z INFO: Sensor SonarJS Coverage [javascript] (done) | time=8ms

So for the time being i had to replace all folder namens in the locv.info with /github/workdir.

In my case i used

    - name: 'Run npm lint and test'
      shell: bash
      run: |
        pushd .
        npm ci
        npm run lint:ci
        npm run test --if-present
        sed -i 's+/home/runner/work/jobreporter/jobreporter+/github/workspace+g' test/unit/coverage/lcov.info
        sed -i 's+/home/runner/work/jobreporter/jobreporter+/github/workspace+g' eslint-report.json

After that the coverage was reported correctly. Maybe that helps

Regards Mathias

score 0 · Answer 2 · answered Apr 22 '20 at 20:14

I had the same problem with a Node build, where the paths in the lcov.info are not the same as the one in the Github Action docker container.

To work around it, I do my builds not by setting up Node directly in the worker, but by using a Docker Action, so that my paths stay the same in all Actions. If you dig in the logs, you can see precisely how the docker actions are run, and the available environment.

For reference, my actions look like this

  - name: 'yarn install'
  uses: docker://node:10.16.3-buster
  with:
    args: yarn install
  env:
    NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
    CI: true

The downside is that my builds are a bit slower, but all my actions are run in Docker, which I find cleaner.

score 0 · Answer 3 · answered Nov 29 '20 at 15:33

To get past this error you need to run your tests with the --blame parameter.

Here is my GitHub action for building and pushing to SonarCloud.

name: Build and run tests
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
      with:
        # Disabling shallow clone is recommended for improving relevancy of reporting for sonarcloud
        fetch-depth: 0
    - name: Setup .Net SDK (v5.0)
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: '5.0.100'
    - name: Install dependencies
      run: dotnet restore
    - name: Build
      run: dotnet build --configuration Release --no-restore
    - name: Test
      run: dotnet test --blame --no-restore --verbosity normal /p:CollectCoverage=true /p:CoverletOutputFormat=opencover /p:CoverletOutput=opencover.xml
    - name: SonarCloud Scan
      uses: sonarsource/sonarcloud-github-action@master
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

SonarCloud code coverage remains 0.0 in GitHub Actions build

3 Answers3