Using coverage.xml with SonarQube Scan from a Different Agent (Linux)

Hello SonarQube Community,

We have generated a coverage.xml file using xcov to the generic report generator, and we would like to use this coverage.xml to run a SonarQube scan from a separate Linux agent. The file was created using microsoft hosted mac agent but since our sonarqube is self hosted, we cannot use the ms hosted agent for sonar scan. We published the coverage.xml and then downloaded it in linux agent (self hosted) to scan it.

My question is: can this setup work? Specifically, we are wondering if SonarQube can correctly process the coverage.xml file generated by xcov on a different agent, and if there are any special configurations or considerations to make this work smoothly.

Any insights or best practices would be greatly appreciated!

We are using * Developer Edition

  • v2025.1 (102418) of sonarqube, and xcode version 16.

Thank you!

Hi,

Welcome to the community!

I’m skeptical of this part:

What language are we talking about here, and is there a language-specific coverage report supported for it?

The paths in the coverage report need to match the paths analysis is seeing. It’s possible for this kind of environment switch to work if the paths are all the same, but typically people struggle with this kind of setup.

 
HTH,
Ann

Thank you Ann.

We used this solution to generate the generic coverage report sonar-scanning-examples/swift-coverage/swift-coverage-example/xccov-to-sonarqube-generic.sh at master · SonarSource/sonar-scanning-examples.

The issue we’re facing is since our sonarqube instance is not accessible from microsoft hosted agent, we’re trying to run sonar scan from self hosted linux agent by using same coverage.xml. But as you said the paths are different, in Coverage.xml its like this probably because of how analyzer created it:
/Users/runner/work/appname/appname/test/test/test/test/test/test.swift

When we run sonar scan using same file as is, coverage is reported 0% because in sonarqube the filename is test/test/test/test/test/test.swift

so we tried updating the coverage.xml to change the paths, but after updating Coverage.xml we receive this error

ERROR Error during parsing of the generic coverage report

Hi,

Well, the rest of that error probably tells what’s wrong with the updated report. Care to share it?

 
Ann

Hi Ann,

For successful run where coverage is reported 0% when we scan file without updating file path:
16:08:34.364 INFO ------------- Run sensors on project
16:08:34.564 INFO Sensor Generic Coverage Report
16:08:34.564 INFO Parsing /home/runner/_work/appname/appname/downloaded-artifact/Coverage.xml
16:08:34.961 INFO Imported coverage data for 0 files
16:08:34.961 INFO Coverage data ignored for 2439 unknown files, including:
16:08:34.963 INFO Sensor Generic Coverage Report (done) | time=397ms
16:08:34.963 INFO Sensor Zero Coverage Sensor
16:08:35.233 INFO Sensor Zero Coverage Sensor (done) | time=270ms
16:08:35.242 INFO SCM Publisher SCM provider for this project is: git
16:08:35.245 INFO SCM Publisher 2378 source files to be analyzed
16:08:35.253 WARN Shallow clone detected, no blame information will be provided. You can convert to non-shallow with ‘git fetch --unshallow’.
16:08:35.255 INFO SCM Publisher 0/2378 source files have been analyzed (done) | time=10ms
16:08:35.260 WARN Missing blame information for the following files:
filenames
16:08:35.473 WARN This may lead to missing/broken features in SonarQube
16:08:35.938 INFO CPD Executor 193 files had no CPD blocks
16:08:35.939 INFO CPD Executor Calculating CPD for 1874 files
16:08:36.673 INFO CPD Executor CPD calculation finished (done) | time=707ms
16:08:36.679 INFO SCM revision ID ‘2810702322d1744ac3eb9f468647919b01babab8’
16:08:37.617 INFO SCM writing changed lines
16:08:37.636 WARN Could not find ref ‘trunk’ in refs/heads, refs/remotes, refs/remotes/upstream or refs/remotes/origin
16:08:37.636 INFO SCM writing changed lines (done) | time=16ms
16:08:37.884 INFO Analysis report generated in 963ms, dir size=19.3 MB
16:08:42.009 INFO Analysis report compressed in 4125ms, zip size=7.9 MB
16:08:42.483 INFO Analysis report uploaded in 474ms
16:08:42.485 INFO ANALYSIS SUCCESSFUL, you can find the results at: sonarqube link

For failed task after updating file path:

14:44:29.315 INFO ------------- Run sensors on project
14:44:29.401 INFO Sensor Generic Coverage Report
15:31:20.370 INFO Parsing /home/runner/_work/appname/appname/downloaded-artifact/Coverage.xml
15:31:20.677 ERROR Error during parsing of the generic coverage report ‘/home/runner/_work/appname/appname/downloaded-artifact/Coverage.xml’. Look at SonarQube documentation to know the expected XML format.
15:31:20.703 INFO EXECUTION FAILURE

Hi,

What comes after EXECUTION FAILURE?

 
Ann

Nothing, no error.

It’s working now, for troubleshooting i reduced the size of file by 99%, and updated the path to be test/test/test/test/test/test.swift from /Users/runner/work/appname/appname/test/test/test/test/test/test.swift manually and reuploaded the file.

Even though the xml earlier was valid as well, its likely updating the whole file at once is causing some issue.

Thank you Ann.

1 Like

Hi Ann,

After a lot of troubleshooting and refactoring the issue seems to be due to filesize. Till filesize of 2-2.3 mb the task compiles successfuly, but from 3mb onwards it throws parsing error even though the file is valid.

My Original file size is 12-13 mb, how can i scan it for coverage?

Do you know if this below mentioned issue was addressed?

sonar-scanner throws parsing error for sonarqube-generic-coverage.xml · Issue #100 · SonarSource/sonar-scanning-examples

Hi,

Wow! Great debugging and thanks for pinpointing this! I’m going to flag this for the experts.

 
Thx,
Ann

Thank you Ann, sorry to rush you but by any chance do you know by when can I expect an update? this is a blocker for us at the moment. Or if you have a ticket I can follow?

Hi,

Hopefully they’ll be along soon.

 
Ann

Hello @apoorv,
Could you please run the analysis with the property -Dsonar.verbose=true and send the logs? We may be able to get more information on the issue.
Also, would you be able to share the coverage report? You can send it by private message.
Thanks

1 Like

Hi Eric, Thank you. Adding verbose helped pinpoint the issue. The diff is, on macos when the app gets compiled some of the dependencies updates the source code and add or expand the number of lines. So a file which originally only had 300 lines, after compilation had 400+, which was covered in coverage.xml, but since when i was running the scan on linux agent with source code and not the compiled code, it was causing a mismatch.

Resolved this by also moving the compiled code to linux agent along with Coverage.xml and it worked fine without any errors this time.

Earlier i thought the issue is different because when i reduced the file size, i did remove a lot of file details, and there were only 3-4 such filenames which were causing this issue. Not all.

2 Likes