Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The XML coverage report generated via PyBuilder can show wrong filenames and packages #862

Closed
lormico opened this issue Jul 28, 2022 · 2 comments

Comments

@lormico
Copy link
Contributor

lormico commented Jul 28, 2022

Bug

When trying to make SonarQube parse the XML coverage file produced with pyb coverage, I found out that in some cases parsing for root-level files fails, because a / is prepended to the filename attribute of the element.

This bug can be replicated by launching pyb coverage on PyBuilder itself and checking the produced target/reports/pybuilder_coverage.xml; for example, one can find:

<class name="__init__.py" filename="/pybuilder/__init__.py" complexity="0" line-rate="0" branch-rate="0">

SonarQube's Python plugin treats filenames starting with / as absolute paths, thus failing to load them for analysis (source here).

Moreover, I noticed that the name attribute in the package element can also be shown in an undesirable way, like in:

<package name=".pybuilder" line-rate="0" branch-rate="0" complexity="0">

Possible fix

I figured out a quick and dirty fix could be appending the OS's file separator to

Please note that files.RELATIVE_DIR, before reassignment, always ends with the file separator.

This way, the examples above become:

<class name="__init__.py" filename="pybuilder/__init__.py" complexity="0" line-rate="0" branch-rate="0">

and

<package name="pybuilder" line-rate="0.5534" branch-rate="0.6269" complexity="0">

Thus leading to correct interpretation of the XML file by SonarQube.

@arcivanov
Copy link
Member

Thank you!

lormico pushed a commit to lormico/pybuilder that referenced this issue Jul 29, 2022
@lormico
Copy link
Contributor Author

lormico commented Jul 29, 2022

No problem 😊 I haven't had yet enough time to delve deep enough in the code to figure out if the file separator can be set directly in the source_path definition here without wreaking havoc on the rest of the plugin:

source_path = nc(project.expand_path(project.get_property("coverage_source_path")))

Do you notice any drawbacks in doing so?

As soon as I can, I'll try to also code some tests for this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants