Add parser for Python coverage #103
Conversation
| <?xml version="1.0" ?> | ||
| <coverage version="6.5.0" timestamp="1710545957568" lines-valid="83" lines-covered="33" line-rate="0.3976" branches-covered="0" branches-valid="0" branch-rate="0" complexity="0"> | ||
| <!-- Generated by coverage.py: https://coverage.readthedocs.io --> | ||
| <!-- Based on https://raw.githubusercontent.com/cobertura/web/master/htdocs/xml/coverage-04.dtd --> |
There was a problem hiding this comment.
Why can't we use the Cobertura parser to read such reports?
There was a problem hiding this comment.
We probably could actually. We've noticed from our internal testing of the default parser changes (documented here), that often times the Python parser will pick up Cobertura reports and vice versa.
Do you think the PythonParser should simply extend the CoberturaParser so as to differentiate when it's a Python project (vs Cobertura seems to be commonly used for Java projects)?
There was a problem hiding this comment.
No. What I mean: we do not need another parser as the CoberturaParser reads all Cobertura reports. Is does not matter if the report is from Java, Python, or anything else.
There was a problem hiding this comment.
I guess the UI in the Jenkins coverage-plugin, which uses this library, doesn't indicate which parser was used to parse and create the coverage model. For users that are generating coverage for their Python project, should we just have them use the Cobertura parser?
There was a problem hiding this comment.
Yes, this is exactly what I mean. Why use a different parser if it does the same thing... Other non-Java teams do use this parser as well with great success.
If it helps we can add another enum value in the Jenkins plugin that provides a "Python Coverage" name, but still uses the existing parser from the model.
|
As mentioned in the review above, this parser does the same thing as the existing Cobertura parser. |
Adding a parser for Python coverage files.
Testing done
Testing was done in both with unit tests and a test coverage file (based on real coverage files). As well as on a local Jenkins, where a local version of the Jenkins coverage-plugin was installed to use this coverage model. Ran a simple Python pipeline and validated the coverage output was available in the UI.
Submitter checklist