ANSI sequences remain in the /consoleText content

[tomcruise81]

Test environment

• Jenkins Version: CloudBees Jenkins Enterprise 2.222.4.3
• AnsiColor Version: 0.7.3
• Operating System running Jenkins:
  • os.arch | amd64
  • os.name | Linux
  • os.version | 3.10.0-1127.10.1.el7.x86_64

Expected behavior

AnsiColor Plugin to strip ANSI sequences from the consoleText / "View as plain text" content

Actual behavior

All ANSI sequences remain in the consoleText content, muddying it up

[tszmytka]

The consoleText endpoint shows the raw log output without involving ansicolor (or any other plugin).
This is the intended behavior. Have you seen a past version of this plugin where it behaved differently?

[tomcruise81]

I believe that when we were at AnsiColor Version 0.4.3, we didn't see the escape sequences in the raw log. I'll see about replicating it.

[tomcruise81]

Confirmed.

AnsiColor 0.4.3 - Raw Output

[Pipeline] {
[Pipeline] stage
[Pipeline] { (ANSI Color Tests)
[Pipeline] ansiColor
[Pipeline] {
[Pipeline] sh
+ set +x
Black
Red
Green
Yellow
Blue
Magenta
Cyan
Gray

Light red
Light green
Light yellow
Light blue
Light magenta
Light cyan
White

AnsiColor 0.7.3 - Raw Output

[Pipeline] {
[Pipeline] stage
[Pipeline] { (ANSI Color Tests)
[Pipeline] ansiColor
[Pipeline] {

[Pipeline] sh
+ set +x
�[38;5;0mBlack�[0m
�[38;5;1mRed�[0m
�[38;5;2mGreen�[0m
�[38;5;3mYellow�[0m
�[38;5;4mBlue�[0m
�[38;5;5mMagenta�[0m
�[38;5;6mCyan�[0m
�[38;5;7mGray�[0m
�[38;5;8mDark gray�[0m
�[38;5;9mLight red�[0m
�[38;5;10mLight green�[0m
�[38;5;11mLight yellow�[0m
�[38;5;12mLight blue�[0m
�[38;5;13mLight magenta�[0m
�[38;5;14mLight cyan�[0m
�[38;5;15mWhite�[0m

[tszmytka]

Thanks for following up.
You are correct in that up till version 0.5.3 ansicolor used to modify the log and strip it clean of ansi sequences. This behavior caused numerous problems and bugs and got heavily reworked in 0.6.0. More info: #132

From this version on the endpoint consoleText shows the raw, unchanged output - as if you ran the pipeline step in a local console.

[tomcruise81]

Bummer. So now consoleText is just muddied up and extremely difficult to read wherever ANSI escape sequences get output. Is there any intention of resolving this?

[tszmytka]

I'm not sure I follow. There is nothing to resolve. The version pre 0.6.0 was causing problems.
What you call "muddied up" is content with the actual ANSI escape codes coming out of your pipeline.

If you don't need them then, depending on the tool you are using, there surely is a way to disable them like mvn --batch-mode. Have you tried that?

[tomcruise81]

Sorry, let me rephrase.

The functionality of ansicolor pre 0.6.0, which colorized console and consoleFull and stripped ANSI escape sequences from consoleText was ideal in that allowed "the best of both worlds" - i.e. colorized output with console and consoleFull, and more concise output with consoleText. I get that the implementation that you all had was causing problems, but was curious if there was any intention on restoring that functionality. It's not our desire to disable colorized output, otherwise we just wouldn't use this plugin...

Thanks!

[jirimacku]

Hi, I also came across this issue. After upgrade we have issues with parsing the consoleText. I would be really nice if the previous functionality (pre 0.6.0) could be restored.

[jirimacku]

BTW the problem seems to be even worth. The ANSI code in the consoleText is malformed and therefore quite difficult to remove via standard tools.

This is the standard ANSI escape for green text:
"\x1b[32mINFO: Executed from groovy-script\x1b[0m"
But this is in the consoleText:
"\x1b[32mINFO: Executed from groovy-script\x1b[m"

The best approach would be to strip the ANSI sequence completely from the consoleText.

[tszmytka]

I understand that relying on a behavior that changes unexpectedly is annoying to say the least, but please understand that the behavior should not have been there in the first place. Let me also be clear that there is 0% chance of it being reinstated.

The way it used to work in pre 0.6.0 days was that ansicolor-plugin intercepted and interfered (removed some chars, added others) with log output coming from a job before it got persisted in a file. Because of this reading up the log file directly from the disk or by means of consoleText gave you output without ANSI escape codes.
Current plugin versions do not alter your job's output in any way (and therefore can't mess it up). What they do is interpret it accordingly when viewed through console and consoleFull. The endpoint consoleText doesn't even pass the content through the plugin so there is no way of stripping it of ANSI sequences.

Not reinstating old behavior is obviously something different than implementing something similar in a new way (maybe as a completely new endpoint) by people who need it. PRs are always welcome.

@jirimacku

But this is in the consoleText:
"\x1b[32mINFO: Executed from groovy-script\x1b[m"

This doesn't seem right on its own - consoleText should show the log file content directly as it was written by the job. Could you please open up a separate issue with a pipeline showing this?

[openjck]

Sorry to comment on an old thread. I just wanted to add some information that might be interesting.

I read an earlier comment how an earlier attempt remove ANSI codes caused more problems than it solved. Would it be easier or more reliable to use a third-party tool to remove ANSI codes? There's a strip-ansi Node module which does a very good job, from my limited testing. I also hear the ansi2txt command from the colorized-logs Ubuntu package also works well. Whether those could realistically be used in a Jenkins plugin written in Java, I don't know.

Unsurprisingly, I'd also love if ANSI escape sequences could be removed from plain text representations of console output, but I know it may not be easy. If the above doesn't help make this more feasible, I'm sorry for adding noise to an old thread.

[dblock]

@openjck Give it a try, there's a pretty decent test suite so you'll know quickly!