Failed to resolve file paths in coverage.xml (Python coverage report) when it's in a subdirectory

SonarCloud
, , ,
1
  • ALM used: GitHub
  • CI system used: GitHub Actions
  • Scanner command used: SonarSource/sonarcloud-github-action@master
  • Languages of the repository: Python

I have a Git repo on GitHub. The repo contains a Python package. I can run tests and generate coverage.xml (Python coverage report) successfully. After that, I can use the GitHub Actions step SonarSource/sonarcloud-github-action@master to scan coverage.xml for SonarCloud to analyze the test coverage. Everything is fine.

However, I’m planning to add another Python package into the Git repo. That means I have to move the current package into a subdirectory, and then create a new package in another subdirectory. I’m changing this:

.
├── LICENSE
├── README.md
├── src
├── setup.py
├── tests
└── tox.ini

into this:

.
├── LICENSE
├── README.md
├── package1
│   ├── src
│   ├── setup.py
│   ├── tests
│   └── tox.ini
└── package2
    ├── src
    ├── setup.py
    ├── tests
    └── tox.ini

After moving the current package into a subdirectory, the GitHub Actions step SonarSource/sonarcloud-github-action@master stopped working properly. The error message says:

INFO: Parsing report '/github/workspace/package1/coverage.xml'
ERROR: Cannot resolve the file path 'src/__init__.py' of the coverage report, the file does not exist in all 'source'.
ERROR: Cannot resolve 16 file paths, ignoring coverage measures for those files

The message suggests that it can find the coverage.xml file, but failed to resolve the source code files that are specified in coverage.xml.

I saw a StackOverflow question that has similar problem as mine, and there is a workaround that uses sed to modify the coverage.xml file. The workaround did work for me, but I don’t think it’s a nice solution.

Is there a better solution for handling Python coverage reports in subdirectories? Thanks.

5

Hello @johnlinp,

First of all, my apologies for the late answer.

It is true that the Python analyzer sometimes has issues to locate source files if the coverage.xml was generated in a different environment than the one in which the analysis is performed (which is the case when using the SonarCloud GitHub action). Surprisingly, we didn’t have a ticket for it, but I just created one now.

Usgin a sed command is a valid workaround in the meantime, although I agree it’s not great. Another workaround is to generate the coverage report setting the relative_files to true (more info here), which might be a cleaner option.

That said, it seems that in your particular case, you might want to set up a monorepo instead of analyzing the whole repository as a single project. This will make your analysis more precise as the analyzer relies on knowing your sources root to compute fully qualified names and perform symbol resolution (and in your case, you seem to have two of those - one for each package - which can lead to incorrect resolution). This setup should also help you if you decide to use the relative_paths option of the coverage tool.

Hope that helps,
Guillaume

7

Thank you for creating the ticket. Let’s wait for the development to complete.