Add captured log msgs to junit xml file

[twmr]

For each tests this adds the captured log msgs to the respective
'system-out' tags in the junit xml output file.

Thanks for submitting a PR, your contribution is really appreciated!

Here's a quick checklist that should be present in PRs:

• Add a new news fragment into the changelog folder
  • name it $issue_id.$type for example (588.bugfix)
  • if you don't have an issue_id change it to the pr id after creating the pr
  • ensure type is one of removal, feature, bugfix, vendor, doc or trivial
  • Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files."
• Target: for bugfix, vendor, doc or trivial fixes, target master; for removals or features target features;
• Make sure to include reasonable tests for your change if necessary

Unless your change is a trivial or a documentation fix (e.g., a typo or reword of a small section) please:

• Add yourself to AUTHORS, in alphabetical order;

[coveralls]

Coverage decreased (-0.006%) to 92.622% when pulling 2d0c1e9 on thisch:junit_xml_log_fix into f2fb841 on pytest-dev:features.

[nicoddemus]

Thanks @Thisch, looks good so far.

I think we should have an option to control that though, I can imagine use cases where users don't want their JUnitXML files to contain logging information, or want their logging to be directed to stderr instead. How about an ini option: junitxml_logging=no/stdout/stderr, defaulting to no to keep backward compatibility?

[twmr]

@nicoddemus, yes, adding an ini flag makes sense. I don't know why one would want to write the captured logs to the <system-err> tag, though. Anyway I've added the junit_logging ini option in my latest commit.

[twmr]

I think we should have an option to control that though, I can imagine use cases where users don't want their JUnitXML files to contain logging information, or want their logging to be directed to stderr instead. How about an ini option: junitxml_logging=no/stdout/stderr, defaulting to no to keep backward compatibility?

@KKoukiou, what do you think?

[KKoukiou]

@Thisch I definitely find it useful. Do you think it might worth to add option about captured log level as well? With my custom fixture for capturing logs, I end up in out memory in my Jenkins when I was capturing all logs including DEBUG. So, without having ability to set default captured log level, unfortunately I can't use this change.

[twmr]

We already have the log_level option, which is taken into account in the junitxml plugin. Have you already tried to set the log_level param to INFO or don't specify it at all (then WARNING is used)?

[nicoddemus]

Looks good, thanks @Thisch!

[KKoukiou]

@Thisch right, thanks :)

[nicoddemus]

Thanks again @Thisch!