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
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.
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.
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:
Finding the coverage.xml file - SOLVED
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
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
@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?
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.
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: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
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)?
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?
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.