[pytest-dev] junitxml update

[Rusty Howell]

In doing some research on this, I see that the py library is in maintenance
mode and "should not be used in new code", according to the docs at
https://pypi.org/project/py/. Are there any concerns with continuing to use
this library going forward?

On Thu, Aug 16, 2018 at 2:52 PM Rusty Howell <rustyhowell at gmail.com> wrote:

> 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/20180817/9209349a/attachment.html>