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
Comments
Thank you! |
lormico
pushed a commit
to lormico/pybuilder
that referenced
this issue
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
Do you notice any drawbacks in doing so? As soon as I can, I'll try to also code some tests for this issue. |
lormico
pushed a commit
to lormico/pybuilder
that referenced
this issue
Jul 29, 2022
lormico
added a commit
to lormico/pybuilder
that referenced
this issue
Aug 7, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 thefilename
attribute of the element.This bug can be replicated by launching
pyb coverage
on PyBuilder itself and checking the producedtarget/reports/pybuilder_coverage.xml
; for example, one can find: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 thepackage
element can also be shown in an undesirable way, like in:Possible fix
I figured out a quick and dirty fix could be appending the OS's file separator to
pybuilder/src/main/python/pybuilder/plugins/python/coverage_plugin.py
Line 352 in f4c50a2
Please note that
files.RELATIVE_DIR
, before reassignment, always ends with the file separator.This way, the examples above become:
and
Thus leading to correct interpretation of the XML file by SonarQube.
The text was updated successfully, but these errors were encountered: