Jenkins console output has these strange characters from grunt command [31m[[39m...

Question

I'm running a grunt-contrib-jshint command using jenkins and the console output is contains text like:

[31m[[39m[33mL425[39m[31m:[39m[33mC29[39m[31m][39m [33mExpected a conditional expression and instead saw an assignment.[39m

Any ideas why? and how to fix it.

Running the same script directly displays:

[L425:C29] Expected a conditional expression and instead saw an assignment.

I've checked the file.encoding setting which was set to MacRoman and after setting export JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 is now UTF-8.

Neoplasticism

Answer 1

Those look like color escape sequences. See if you can pass a parameter like --no-color to the command (if the tool supports it, see this maybe), or look at the AnsiColor plugin

Dexamyl

Thanks, adding the --no-color option to grunt fixed the issue – Neoplasticism

Answer 2

Alternatively, if you like colors, you can use the Jenkins AnsiColor Plugin to properly display the color escape sequences in the build log.

Mather

Answer 3

There is a better alternative if you can install plugins in Jenkins. Just install the AnsiColor plugin and add this to your Jenkinsfile:

options {    
  ansiColor('xterm')
}

Now, not only have you eliminated the annoying character, but you also have colors in the output!

Hexapartite

How do you do this on a scripted pipeline? – Bringingup

Answer 4

What worked for me is...

play -Dsbt.log.noformat=true clean compile test dist

The -Dsbt.log.noformat=true suppressed the colorization of the console output on my Play 2.1.1 builds making the console log on Jenkins readable. Now, how to get the test results in a less XMLy way?

Altricial

Answer 5

It looks like colouring control commands that are being ignored by your shell. In terms of fixing it, it may involve changing the script so that it doesn't produce that output.

Equilateral

Answer 6

I have different solution for this whole issue. In fact, none of the suggestions listed above had worked for me. I was using two types of slaves: CentOS and Ubuntu machines. For some reason the issue was affecting the CentOS machines only, not the Ubuntu machines.

I compared the "System Information" for the two types of slaves and I found out that the file.encoding is set ANSI_X3.4-1968 on CentOS hosts. This is the default. The Ubuntu default is UTF-8.

So, restarting the slave with the Advanced JVM Option -Dfile.encoding=UTF-8 did the trick, without need of suppressing mocha's colors.

Eliaeliades