Failed to resolve files with scoverage

SonarQube Server / Community Build
, ,
1

I have an installation of SonarQube 8.9.6 Developer Edition.

I’m trying to upload a coverage report for a scala project, by using the scoverage plugin.

I run sonar-scanner via Github Actions by using the aciton SonarSource/sonarcloud-github-action@v1.6, with the following config:

      - name: SonarQube Scan
        uses: SonarSource/sonarcloud-github-action@v1.6
        env:
          SONAR_TOKEN: ${{ secrets.SONARQUBE_TOKEN }}
        with:
          projectBaseDir: .
          args: >
           -Dsonar.host.url=${{ secrets.SONARQUBE_HOST }}
           -Dsonar.projectName=${{ github.event.repository.name }}
           -Dsonar.projectKey=${{ github.event.repository.name }}
           -Dsonar.sources=src/main/scala
           -Dsonar.tests=src/test/scala
           -Dsonar.scala.version=2.12
           -Dsonar.scala.coverage.reportPaths="target/scala-2.12/scoverage-report/scoverage.xml"

the report was generated in the step before, by running:

sbt compile coverage test assembly
sbt coverageAggregate

and I can confirm the report is there, and it shows the proper values.

However, when the action is executed in Github, I get:

INFO: Sensor Scoverage sensor for Scala coverage [sonarscala]
INFO: Importing /github/workspace/target/scala-2.12/scoverage-report/scoverage.xml
WARN: Fail to resolve 6 file(s). No coverage data will be imported on the following file(s): /home/runner/work/spark-td/spark-td/src/main/scala/io/split/td/mtks/CustomQueryListener.scala;/home/runner/work/spark-td/spark-td/src/main/scala/io/split/td/mtks/Sink.scala;/home/runner/work/spark-td/spark-td/src/main/scala/io/split/td/mtks/SinkConfig.scala;/home/runner/work/spark-td/spark-td/src/main/scala/io/split/td/util/config/StatsDInitializer.scala;/home/runner/work/spark-td/spark-td/src/main/scala/io/split/td/util/config/ssm.scala;/home/runner/work/spark-td/spark-td/src/main/scala/io/split/td/util/infra/metadata.scala

I have tried running a local copy of SonarQube comunity edition in a docker container, and push the report with sonar-scanner, and I get the expected results.

So the problem is either with the Github Action or with SonarQube Developer Edition.

4

Hi @cfadon,
Are you still facing the same issue? Can you check if the paths in the scoverage report are using an absolute path that might be specific to the Github Action environment?

6

Hello! Did you find a solution to that @cfadon ? We are facing the same issue.
Switching to use Sonar-Scala https://sonar-scala.com/ Works and we get the coverage in SonarCloud but not with the default sonarcloud-github-action plugin and Sonar-scala one does not have support for Scala 3 (what we need).
Any new ideas?
Thank you.

7

Hello @Dorian_Burihabwa I think I know what is happening. Is related to this other problem Test results are not being published to sonarcloud - #8 by gastonschabas

The problem is that coverage report is generated directly on the “/runner/_work/” main directory for Github actions using sbt. But when running it using GitHub - SonarSource/sonarcloud-github-action: Integrate SonarCloud code analysis to GitHub Actions a Docker is run and a volume created to sync the code between
-v “/runner/_work/[my-project]/[my-project]”:“/github/workspace”

This is the message that appears when running the step on Github Actions:

Run sonarsource/sonarcloud-github-action@master
/usr/local/bin/docker run --name e2266ba9a69824544d2da867945a369ad22a_3b53db --label 60e226 --workdir /github/workspace --rm -e "JAVA_HOME" -e "JAVA_HOME_17_X64" -e "MSYS" -e "COURSIER_BIN_DIR" -e "GITHUB_TOKEN" -e "SONAR_TOKEN" -e "INPUT_PROJECTBASEDIR" -e "INPUT_ARGS" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_EVENT_PATH" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "GITHUB_ACTION" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/runner/_work/_temp/_github_home":"/github/home" -v "/runner/_work/_temp/_github_workflow":"/github/workflow" -v "/runner/_work/_temp/_runner_file_commands":"/github/file_commands" -v "/runner/_work/[my-project]/[my-project]":"/github/workspace" 60e226:6ba9a69824544d2da867945a369ad22a -Dsonar.organization=[my-project] -Dsonar.projectKey=[my-projectkey] -Dsonar.projectName=[my-project] -Dsonar.language=scala -Dsonar.scala.file.suffixes=.scala -Dsonar.sources=src/main -Dsonar.tests=src/test,src/it -Dsonar.scala.coverage.reportPaths=../target/scala-3.2.2/scoverage-report/scoverage.xml -Dsonar.scala.version=3.2.2
INFO: Scanner configuration file: /opt/sonar-scanner/conf/sonar-scanner.properties
INFO: Project root configuration file: NONE
INFO: SonarScanner 4.7.0.2747

You can see here the volume created.

Then the sonar scanner is unable to match the format of the coverage file directories that it contains with the current directories for the files in the docker volume and it simply does not account it so coverage is marked to 0%.

Probably changing the volume docker internal directory to match what is used by GitHub actions will solve the problem.

As sbt-sonar plugin has a build-in Sonar scanner, it does not run in a docker container, there is no volume and directory change either, so it works smoothly.

Can anyone help confirm this? Thanks.

8

I was right but not the first who identify this problem.
There is a workaround using this fix for the Sonarcloud action a true spirit created! :slight_smile:

Please, guys, fix this whenever you can. Thank you.

12

Hello again,

This is an old topic and so far @JordiGiros’s solution seems to be the best way to go in a Github/Sonarcloud pipeline but I have opened a ticket to track this.