Following the advice here I added this line in a bash task immediately after the task in which I create my combined coverage.xml:
sed -i 's/C:\/hostedtoolcache\/windows\/Python\/3\.7\.8\/x64\/Lib\/site-packages/MySource/g' coverage.xml
In my sonar-project.properties file I have this (MySource is just made up here):
sonar.sources=MySource
Then SonarQube was able to show my coverage results as expected, and these of course matched the view in the Code Coverage tab of the build summary UI in DevOps.
So it seems the file paths in coverage.xml must be discoverable under the sonar.sources folder. The problem is that SonarQube is analysing my checked-out source code but I’m running the actual unit tests and coverage.py against the installed code. I want to do the latter because I believe it’s a more realistic scenario for end-users, plus I have to install my python package anyway because it’s using C++ extensions. In other words, running the tests from the Python source code alone simply wouldn’t work.
I suspect that if coverage.py and SonarQube were both pointed at the checked-out code then this zero coverage issue in SonarQube wouldn’t happen. But I can’t do that.
If anyone knows of a better workaround than hacking coverage.xml for my use-case that would be greatly appreciated:).