scoverage / sbt-scoverage

sbt plugin for scoverage
Apache License 2.0
650 stars 157 forks source link

Failed to resolve files with SonarQube in GitHub Actions #448

Open Israphel opened 2 years ago

Israphel commented 2 years ago

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.

Is there a problem with this tool in Github Actions in particular?

ckipp01 commented 2 years ago

Hey, thanks for the report. Looking at the last line it seems that error is coming from SonarQube right? Do you have any more information on that side about exactly what that means? Does it just mean that it's unable to find those files, or maybe something else? Are you sure the path is right? I'm not sure how the setup works but I see spark-td/spark-td/src/main in the missing paths, but I see in the sourceroot is src/main/scala? How come there is two different spark-td? Is that just the module name?

Israphel commented 2 years ago

yes, that error is from the SonarQube scanner, inside Github Actions

GHA will clone to /home/runner/work/$repo_name

then the repo of course includes src/main/scala etc

the sonar scanner works fine locally, but not inside GHA. I'm suspicious of some problem with GHA using symlinks for the folder.

scottrice10 commented 2 years ago

I ran into this too. The SonarCloud Github Action is using a docker container, which Github Actions runs as docker in docker, where they mount the current Github Action working directory onto /github/workspace. The reports generated by sbt-scoverage (and sbt-scapegoat) use absolute paths to the original working directory, but this only works if the paths are instead to the new mounted directory. The Github Action Dockerfile docs vaguely mention this.

The workaround I've found is to rewrite the absolute paths to what's expected.

- name: Rewrite absolute paths to point to mounted directory used in the next step
   shell: bash
   run: |
      find . -type f \( -name "*scoverage.xml" -or -name "*scapegoat-scalastyle.xml" \) -exec sed --in-place "s|$GITHUB_WORKSPACE|/github/workspace|g" {} \;
- name: SonarCloud Scan
  uses: sonarsource/sonarcloud-github-action@master
  env:
      GITHUB_TOKEN: ${{ inputs.github-token }}
      SONAR_TOKEN: ${{ steps.secrets.outputs.sonarToken }}
Israphel commented 2 years ago

interesting, I will try that

Israphel commented 2 years ago

everything works as expected by doing that workaround.

I think it will be worth mentioning somewhere that scoverage won't work as expected when combined with Sonarqube and github actions