Mapping coverage.xml paths to filesystem

Building a python project using GitHub Actions, the build environment is docker based. The resulting code coverage.xml file has paths that are correct for the Docker build environment but do not map correctly to the filesystem on the GitHub Runner. This results in SonarQube errors:

21:07:24.435 INFO: Sensor Cobertura Sensor for Python coverage [python]
21:07:24.436 DEBUG: Using pattern '/github/workspace/example-project-dev-env/ws/example-project/coverage.xml' to find reports
21:07:24.504 INFO: Python test coverage
21:07:24.507 INFO: Parsing report '/github/workspace/example-project-dev-env/ws/example-project/coverage.xml'
21:07:24.550 WARN: Invalid directory path in 'source' element: /home/dev/repo/ws/example-project/app
21:07:24.552 ERROR: Cannot resolve the file path 'api/__init__.py' of the coverage report, the file does not exist in all 'source'.
21:07:24.619 ERROR: Cannot resolve 176 file paths, ignoring coverage measures for those files
21:07:24.620 DEBUG: Saving coverage measures for file '__init__.py'
21:07:24.625 INFO: Sensor Cobertura Sensor for Python coverage [python] (done) | time=190ms

How do other people handle this?

Hi,

I notice that this is a relative path, which I would assume should exist in your project structure regardless of where it’s checked out to.

What is the actual path of that file, relative to project root, on the GitHub Runner?

 
Ann

The path of the file is relative to project root.

1 Like

Can project root be defined in sonar-project.properties or is it always based on where sonar-scan is executed from?

Hi,

Ideally (everything’s just way easier that way) project root is where analysis is kicked off from / is where sonar-project.properties is. And sonar.projectBaseDir is an option to reset that. The docs.

 
HTH,
Ann

So this is starting to make a bit of sense.

  1. UT executes in a Docker container where Docker / does not map to the workspace / where sonar-project.properties is.
  2. A coverage.xml is generated and then accessed from the workspace /
  3. sonar-scan gets upset when it sees Docker / and workspace / differences between coverage.xml and files in workspace /

I think.

Hi,

If the paths in the report are relative to project root & the project structure looks exactly the same in both Docker and your workspace, then you might get away with what you’ve described. Otherwise, yes. There will be problems.

 
HTH,
Ann

Follow up question. When there are WARN issues with the path in coverage.xml, does that mean the entire coverage analysis will be rejected? Asking because while we are seeing WARN for some files, we are also seeing 0 coverage report details.

Just to be clear, we’ve moved though the issue a bit:

  1. Finding the coverage.xml file - SOLVED
  2. File is read by some paths in the coverage.xml file do not map to the build directory and are excluded. WARN is issued in the log for this. It’s not clear if that WARN would prevent the entire code coverage from being reported - OPEN QUESTION
  3. We are seeing in the PR decoration 0 Code Coverage as shown. This is the really meat. This is what we want to solve. - OPEN ISSUE

image

Hi,

Nope. It’s simply a warning & affects only the file(s) in the warning(s).

Can you share your analysis log?

 
Ann

1 Like

@ganncamp sorry, can you be more specific on the log request? Is this what we see in the GitHub Actions stage or something from the SonarQube server side?

Hi,

Yes, this would be the GH Action logs for the analysis step.

 
Ann

Thanks @ganncamp. How can I get this log to you? While there are no secrets in the logs, repo names and file paths are sensitive info for HPE and not something we can post openly.

Hi,

Feel free to redact as necessary.

 
Ann

That’s going to be a bit challenging. I can start by offering up these bits that look important to me. What else am I looking for? I really appreciate the help!

2022-09-15T22:32:31.8345201Z 22:32:31.833 INFO: Sensor Python Sensor [python] (done) | time=21123ms
2022-09-15T22:32:31.8351818Z 22:32:31.834 INFO: Sensor Cobertura Sensor for Python coverage [python]
2022-09-15T22:32:31.8366605Z 22:32:31.836 DEBUG: Using pattern '/github/workspace/***-dev-env/ws/***/coverage.xml' to find reports
2022-09-15T22:32:31.9234438Z 22:32:31.922 INFO: Python test coverage
2022-09-15T22:32:31.9270355Z 22:32:31.926 INFO: Parsing report '/github/workspace/***-dev-env/ws/***/coverage.xml'
2022-09-15T22:32:32.0513905Z 22:32:32.050 INFO: Sensor Cobertura Sensor for Python coverage [python] (done) | time=216ms
2022-09-15T22:32:32.0514929Z 22:32:32.050 INFO: Sensor PythonXUnitSensor [python]
2022-09-15T22:32:43.4436706Z 22:32:43.442 INFO: CPD Executor CPD calculation finished (done) | time=301ms
2022-09-15T22:32:43.4512773Z 22:32:43.450 DEBUG: SCM revision ID '39cca4dbe50c59cd5787c40c6f8546014f8e76cd'
2022-09-15T22:32:43.5207006Z 22:32:43.520 INFO: SCM writing changed lines
2022-09-15T22:32:43.5219536Z 22:32:43.521 DEBUG: loading config FileBasedConfig[/tmp/jgit/config]
2022-09-15T22:32:43.5270196Z 22:32:43.526 INFO: Merge base sha1: d80aa3824d54cba2f59166f1a3929398745bf450
2022-09-15T22:32:43.5276535Z 22:32:43.527 DEBUG: SCM reported changed lines for 0 files in the branch
2022-09-15T22:32:43.5277123Z 22:32:43.527 INFO: SCM writing changed lines (done) | time=7ms
2022-09-15T22:32:43.5430483Z 22:32:43.542 INFO: Analysis report generated in 85ms, dir size=886.3 kB
2022-09-15T22:32:43.9536584Z 22:32:43.953 INFO: Analysis report compressed in 410ms, zip size=438.7 kB
2022-09-15T22:32:43.9541694Z 22:32:43.953 INFO: Analysis report generated in /github/workspace/.scannerwork/scanner-report
2022-09-15T22:32:43.9542588Z 22:32:43.953 DEBUG: Upload report
2022-09-15T22:32:44.3002451Z 22:32:44.299 DEBUG: POST 200 ***/api/ce/submit?projectKey=glcp_***_AYMZYYUf5gHz8aoxutFt&characteristic=pullRequest%3D138 | time=345ms
2022-09-15T22:32:44.3056875Z 22:32:44.305 INFO: Analysis report uploaded in 351ms
2022-09-15T22:32:44.3078026Z 22:32:44.307 DEBUG: Report metadata written to /github/workspace/.scannerwork/report-task.txt
2022-09-15T22:32:44.3080261Z 22:32:44.307 INFO: ANALYSIS SUCCESSFUL, you can find the results at: ***/dashboard?id=glcp_***_AYMZYYUf5gHz8aoxutFt&pullRequest=138
2022-09-15T22:32:44.3082213Z 22:32:44.307 INFO: Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report
2022-09-15T22:32:44.3083817Z 22:32:44.307 INFO: More about the report processing at ***/api/ce/task?id=AYNDSG_MKfDTK_E4AQxp

Hi,

I’m not seeing anything out of the ordinary in what you’ve provided. Let’s back up: tell me about the PR. Are you sure that the changes in it include changes to coverable code (as opposed to e.g. changes to config files)?

 
Ann

No, the PR doesn’t include changes to code coverage (eg, more tests added).

However, we do execute coverage, generate a coverage.xml, and pass that to sonar-scanner in the PR. The see the decoration as posted above and it says “No Coverage information” which isn’t accurate since we see sonarqube pick up the coverage report?

if we look at the branch instead of the PR we see 0.0%. We tried this on a fresh branch so it should show something I would expected.

Most of the functions have decorators. would that impact code coverage?

Hi,

PR analysis covers the code changed in the PR. If your PR only adds tests, then it’s quite natural that you get odd coverage results.

Regarding the branch, I’m not sure what do say. We’d be back to your analysis logs. But at this point, we’re a bit far afield from “mapping coverage.xml paths to filesystem”, so I’d need you to start a new thread, please.

 
Ann