I personally like the idea of a junit version flag "--junitxml_vesion=x.x" and then in the junitxml module perhaps have a subclass that handles each of the different versions. If the flag is omitted, the default would be the latest junit schema. This would also allow us to fix issues on older junit version (if we miss something), and if the schema changes, adding a new junit format would be straightforward I think. The big issue I see is finding authoritative documentation for the various schemas. In the comments in one of the bugs, there is a link to apache.org and their xsd. This is a good start. But this is just looking at the Junit Test Report Plugin in Jenkins. Are there other xml-consuming reporting tools that are popular enough to support as well?
I think to begin with, I will work on seeing what it will take to create a baseclass/subclass for a particular junit version, and adding in any extra command line args. Once I have a proof of concept, I'll comeback and share what I have before I move forward. Rusty On Thu, Aug 16, 2018 at 11:56 AM, Floris Bruynooghe <[email protected]> wrote: > On Thu 16 Aug 2018 at 15:10 +0200, RonnyPfannschmidt wrote: > > Im fine with any other proposal that sorts out the breakage dimensions > > to be expected > > Is this the problem where junitxml changes slightly in a new jenkins > release and fixing it requires an update to the plugin? At this point > users will either have to not update jenkins or update the external > plugin or update all of pytest if the plugin stays internal. I don't > think the release cycle of pytest is so slow there is a major benefit to > moving it external for this? Given that IIUC Rusty is proposing the > plugin would be able to generate older incompatible versions (e.g. with > --junit-version=x) this would work AFAIK. > > Happy to hear where I'm wrong though. > > (I'm kind of +1 on Bruno's opinion of keeping it in the core btw, we > should enable ppl to easily contribute to junitxml in the core which I > believe our current contributing policies do) > > Cheers, > Floris > _______________________________________________ > pytest-dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/pytest-dev >
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
