Skip to content

deprecate the builtin junitxml module and plan for moving it to a external plugin #3777

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
4 tasks
RonnyPfannschmidt opened this issue Aug 3, 2018 · 5 comments
Labels
plugin: junitxml related to the junitxml builtin plugin type: backward compatibility might present some backward compatibility issues which should be carefully noted in the changelog type: deprecation feature that will be removed in the future type: removal marks the actual removal of a feature, usually done in major releases

Comments

@RonnyPfannschmidt
Copy link
Member

followup to #1126

junitxml in pytest itself is broken and not seeing any real maintenance, as such it should be considered for removal from the core

  • create a timeline
  • create a external copy of the plugin that may replace/superseed the building plugin
  • deprecate the builtin plugin
  • remove the builting plugin

as the plugin is not part of the public api, it can be turned into a required dependency even in a minor release without needing to have a breaking release

it can however only turned into a optional thing by a major release

@RonnyPfannschmidt RonnyPfannschmidt added type: backward compatibility might present some backward compatibility issues which should be carefully noted in the changelog plugin: junitxml related to the junitxml builtin plugin type: deprecation feature that will be removed in the future type: removal marks the actual removal of a feature, usually done in major releases labels Aug 3, 2018
@nicoddemus
Copy link
Member

Not sure I like the idea of the core depending on an external plugin, because the external plugin will also depend on pytest.

@rustyhowell
Copy link

rustyhowell commented Aug 13, 2018

I wouldn't mind taking a stab at updating and maintaining junitxml. I depend on this feature for work and am currently stuck on older Junit test report plugin in Jenkins because the newest one changes schema. I hastily submitted a merge request a few days ago, but it's clear that more thought has to be involved here. If we can come to a consensus on the direction of this feature, I am willing to do the work.

I see a couple of possible directions:

  1. Make the breaking changes necessary and maintain compatibility with Jenkins Junit test plugin in the future (even if they change schema again).
  2. Change this feature to be more generic (ie --xunitxml) and keep it as is, and create a new external plugin for Jenkins Junit parity.

@RonnyPfannschmidt
Copy link
Member Author

@rustyhowell i'd like to coordinate this on the ml

i'd really like to get into a place where the junitxml plugin is aware of flavors and versions, and able to function in a context where pytest was executed logging serialized reports, and then using those reports to genrate the junitxml

@nicoddemus
Copy link
Member

@rustyhowell has the new junit_family option been working for you?

@nicoddemus
Copy link
Member

Closing this the plugin has seen both interest and maintenance in the last releases, so it seems it should stay on the core (for now).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugin: junitxml related to the junitxml builtin plugin type: backward compatibility might present some backward compatibility issues which should be carefully noted in the changelog type: deprecation feature that will be removed in the future type: removal marks the actual removal of a feature, usually done in major releases
Projects
None yet
Development

No branches or pull requests

3 participants