rspec_junit_formatter: Problems parsing XML created with 0.3.pre3

Hi 👋 Thanks for working on this project 🙇 We’ve been using rspec_junit_formatter for a while on a one of our projects to format the output of specs into something readable by Jenkins. We started a fresh project recently and ran into an old issue that we hacked around previously.

We run into problems when we enable colored output in RSpec — we want colors to show in Jenkins console output, but if ANSI escape codes end up in the XML it renders the XML unreadable to Jenkins. I’ve seen the freshest versions of the gem and thought it would address the issues cleanly, however, Jenkins still complains about invalid XML. As a matter of fact, even Safari and Chrome complain about the structure of the XML with error messages similar to:

error on line 2 at column 14: xmlParseCharRef: invalid xmlChar value 27

The characters are indeed escaped correctly (i.e. \u1b is correctly escaped as ), but even the escaped character is not valid in XML. So I think for some classes of characters, the best solution is to simply remove them from the output.

For instance, when you save the output of the example spec to a file and try to open with Safari or Chrome, I get the following render:

I’ll gladly help with a pull request, but I’m not sure what’s the best way to proceed. Initially I wanted to remove only ANSI escape codes, but apparently it’s a broader issue and maybe some characters should simply be removed instead of trying to escape them.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 18 (10 by maintainers)

Most upvoted comments

The base text formatter calls #fully_formatted on a bunch of the notifications. These methods take a colorizer which is RSpec::Core::Formatters::ConsoleCodes by default which decorates things with ANSI codes. In the JUnit formatter I’m calling the non fully-formatted versions of these which call other methods which use a NullColorizer to avoid the codes. So for the most part the output isn’t colorized, and this is independent of the color options on the command line.

The diff, however, is appended to the message and is calculated against a differ constructed with the global color argument. So by the time this message hits the formatters it has already had the coloring baked into it based on the command line arguments.

Oh dear! I just tried using 3.5.0 and 3.5.4 and I still couldn’t replicate what you were seeing I’m afraid. Glad an upgrade made it go away, though!

Sounds like the problems solved so I’ll close this ticket. v0.3.0 should be out for real, soon!