[pytest-dev] junitxml update

[Rusty Howell]

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 <flub at devork.be> 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
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180816/3e9acf86/attachment.html>