[pytest-dev] junitxml update

[Floris Bruynooghe]

Hi Rusty,

On Fri 17 Aug 2018 at 22:08 -0600, Rusty Howell wrote:

> 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?

Given that this team also maintains the py library there's no issue with
keeping using it for anything for which we already use it.  So anything
from the py library which is already being used by pytest you can
happily keep using.

If you want to start using new things from the py lib then maybe ping
this list first to see if that's still the best solution.

Cheers,
Floris


> 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
>>>
>>
>>