|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
NOTE: This is NOT related! We had a real error messaging being fired off by one of our tests and Jenkins was just passing it along. Apologies for the distraction! That said, the actual UTF does not make it into the error report (Chinese characters in this case) so at some point in the chain the UTF is lost. On a terminal, the same test displays the error message and the original UTF.
We have what might be a related issue. Several of our Rspec tests contain UTF-8 characters. These are stored as UTF-8 text files, have the comment #encoding: utf-8 at the top which hints to Ruby that the source code is not ascii, and perform perfectly in our test suite. When the Jenkins job is complete, a gem called ci_reporter compiles our test results into a reports directory. Somewhere in that after(:all) hook the following error is thrown:
{{ An error occurred in an after(:all) hook. Errno::EPERM: Operation not permitted - Operation not permitted - some/�备环/cool境应/path/用�动 occurred at org/jruby/RubyFile.java:1063:in `unlink' }}
The build goes on to succeed, but I think processing this unicode in the XML is causing either an issue. The RubyFile.java reference makes me think this might be our version of jruby (locked at 1.7.1 might be the villain). But I wanted to add this here in case a piece of the Jenkins stack has UTF sensitivities in XML. I think that is unlikely but more information may help us all track this to the root cause. Cheers! C