-
-
Notifications
You must be signed in to change notification settings - Fork 122
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
Different line number representation (xunit) #779
Comments
Thank you for the report. Looks this project you reference decided yet another format for line numbers. The action itself supports already the most common variants of line numbers, via either Alternative it supports the common format of Do you have the chance to adjust the format? The most reliable would be to have |
After reviewing this, I can also see that the file paths arent matched correctly as well |
Changing the xml file format isnt really an option in this scenario, I was wondering if from the name attribute the - can be used to split the file path and line numberings to give the desired behaviour. <?xml version="1.0" ?>
<testsuite errors="544" failures="0" name="prospector-dodgy-mccabe-profile-validator-pycodestyle-pyflakes-pylint" tests="544" time="33.46">
<properties/>
<system-out><![CDATA[]]></system-out>
<system-err><![CDATA[]]></system-err>
<testcase name="truelearn_experiments/analyse_results.py" line="54">
<error message="String statement has no effect" name="pylint Error"><![CDATA[truelearn_experiments/analyse_results.py:54: [pointless-string-statement(pylint), None] String statement has no effect]]></error>
</testcase>
</testsuite> |
Hello @mikepenz
When parsing xunit output the tool works except for the line numberings. For the following output no line numbers are found hence it defaults to 1:
Shown as Github annotations:
The format of this output is as follows:
As per the xunit output of prospector: https://github.com/PyCQA/prospector/blob/master/prospector/formatters/xunit.py
The text was updated successfully, but these errors were encountered: