Покрытие кода SonarCloud остается 0,0 в сборке GitHub Actions

Я настроил CI для решения .NET Core с помощью GitHub Actions. Когда код передается в главную ветвь, создается решение, запускаются модульные тесты и выполняется анализ кода с помощью SonarCloud. Шаг анализа кода фактически выполняется sonarcloud-github-action.

Граница качества в SonarCloud не проходит, потому что процент покрытия составляет 0,0% (как для нового, так и для существующего кода). Я создаю отчеты о покрытии кода с помощью Coverlet. Файл extension.opencover.xml успешно создается после выполнения теста для каждого проекта модульного тестирования. В файле sonar-project.properties я ссылаюсь на эти файлы следующим образом:

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

Но очевидно, что отчеты о покрытии кода распознаются, но не обрабатываются сканером SonarCloud. В журнале рабочего процесса GitHub Actions я вижу эти предупреждения:

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

Пытаясь устранить предупреждение «Отсутствует информация об обвинении», я добавил файлы покрытия к исключениям в моем проекте SonarCloud: **/coverage.opencover.xml, но это не решило проблему. Предупреждение по-прежнему появляется, а покрытие кода по-прежнему составляет 0,0%.

Есть какие-нибудь подсказки, как это сделать?

[редактировать]:

Мой рабочий процесс в GitHub Actions выглядит так:

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 }}

`


person ngruson    schedule 15.11.2019    source источник
comment
Трудно помочь, не видя своего рабочего процесса. Пожалуйста, добавьте его к своему вопросу, если можете. Файловая система сохраняется между шагами, но не заданиями, поэтому убедитесь, что оба действия выполняются в одном задании.   -  person peterevans    schedule 15.11.2019


Ответы (3)


У меня была аналогичная проблема с работой охвата проекта Typescript. Без ваших журналов сонара я просто могу догадаться, но проблема заключалась в том, что пути внутри lcov.info, где абсолютный путь от github, что-то вроде SF:/home/runner/work/YoutRepoName.., и Sonar запускал контейнер Docker и устанавливал рабочий каталог на /github/workdir и поэтому не мог найти файлы из lcov.info.

Проверьте свои журналы, если вы найдете что-то вроде

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

Так что пока мне пришлось заменить все имена папок в locv.info на /github/workdir.

В моем случае я использовал

    - 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

После этого о покрытии сообщили правильно. Может это поможет

С уважением, Матиас

person Mathias Maerker    schedule 29.11.2019

У меня была такая же проблема с сборкой узла, где пути в lcov.info не совпадают с путями в докер-контейнере Github Action.

Чтобы обойти это, я делаю свои сборки не путем настройки Node непосредственно в worker, а с помощью Docker Action, чтобы мои пути оставались одинаковыми во всех действиях. Если вы покопаетесь в журналах, вы можете точно увидеть, как выполняются действия докеров, и доступную среду.

Для справки, мои действия выглядят так

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

Обратной стороной является то, что мои сборки немного медленнее, но все мои действия выполняются в Docker, который я считаю более чистым.

person Romain Prévost    schedule 22.04.2020

Чтобы избежать этой ошибки, вам необходимо запустить тесты с параметром --blame.

Вот мое действие на GitHub по созданию и продвижению в 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 }}
person Ryan O'Neill    schedule 29.11.2020