There is some additional discussion on https://github.com/jenkinsci/ansicolor-plugin/issues/145. I am not sure exactly what the issue is with ansible, but it looks like at least Terraform is using multiline input, which I think should be fixed by https://github.com/jenkinsci/ansicolor-plugin/pull/137 (merged but not released). If anyone seeing the issue can test out the attached SNAPSHOT build of the plugin based on the current master (ansicolor.hpi) and report on whether that fixes the issue, makes things better, makes things worse, or makes no difference, that would be very helpful.

ansicolor.hpi

I tried this snapshot and it's makes no difference...

Thanks for trying it out vektory79! It would be great if anyone seeing the issue could report whether they are seeing variant 1 or 2 of the issue while ansicolor 0.6.x is installed as described in my comment on the GitHub issue.

If ansicolor 0.6.x is installed then I see the 1 variant of the issue.

Are there any error messages in your logs? Do you see any kind of coloration in any jobs? What tools are producing colorized output in your logs (Ansible)? Can you copy-paste one of the lines that is showing up incorrectly here (preferably replacing literal occurrences of the character 0x1B with 0x1B here so we can see how control characters are being processed?)

> Are there any error messages in your logs?

I haven't found any meaningful messages.

> Do you see any kind of coloration in any jobs?

No at all.

> What tools are producing colorized output in your logs (Ansible)?

Apache Maven 3.6.0 (with special flags to force the coloration).

> Can you copy-paste one of the lines that is showing up incorrectly here

[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] ru.krista:root:pom [pom]
[INFO] ru.krista:core:pom [pom]
[INFO] ru.krista.core:common:pom [pom]
[INFO] ru.krista.core.common:utils:jar [takari-jar]
[INFO] ru.krista.core:ioc:pom [pom]

 > preferably replacing literal occurrences of the character 0x1B with 0x1B here so we can see how control characters are being processed?

Sorry, but I don't know how to do this... I just see this log instead of color text. With 0.5.3 all colors is in place here.

> preferably replacing literal occurrences of the character 0x1B with 0x1B here so we can see how control characters are being processed?

Sorry twice! I found them!

[0x1B[1;33mWARNING0x1B[m]
[0x1B[1;33mWARNING0x1B[m] It is highly recommended to fix these problems because they threaten the stability of your build.
[0x1B[1;33mWARNING0x1B[m]
[0x1B[1;33mWARNING0x1B[m] For this reason, future Maven versions might no longer support building such malformed projects.
[0x1B[1;33mWARNING0x1B[m]
[0x1B[1;34mINFO0x1B[m] 0x1B[1m------------------------------------------------------------------------0x1B[m
[0x1B[1;34mINFO0x1B[m] 0x1B[1mReactor Build Order:0x1B[m
[0x1B[1;34mINFO0x1B[m]
[0x1B[1;34mINFO0x1B[m] ru.krista:root:pom [pom]
[0x1B[1;34mINFO0x1B[m] ru.krista:core:pom [pom]
[0x1B[1;34mINFO0x1B[m] ru.krista.core:common:pom [pom]
[0x1B[1;34mINFO0x1B[m] ru.krista.core.common:utils:jar [takari-jar]
[0x1B[1;34mINFO0x1B[m] ru.krista.core:ioc:pom [pom]

vektory79 Maven coloring is explicitly validated in this test case. Are you sure that you are seeing that output for a build while you are still running Ansicolor 0.6.0? If you have Ansicolor 0.5.3 installed, then the logs are expected to look like that for builds that originally ran while Ansicolor 0.6.0 was installed. I am not able to reproduce your issue on Ansicolor 0.6.0. If you are able to create a similar test case to the Maven one I linked that demonstrates the issue you are seeing, that would be very helpful.

Fairly minimal test case:

• docker run -p 8080:8080 -p 50000:50000 jenkins/jenkins:2.150.2
• Go to http://localhost:8080
• Don't install any plugins
• Go to Plugin Manager, install AnsiColor 0.5.3 from https://updates.jenkins.io/download/plugins/ansicolor/
• Create a free-style job with "Color ANSI Console Output", and a build step "Execute shell" containing: echo "\e[1m\e[34mbold blue text\e[0m\e[0m"
• Build the job. Output bold blue text
• Go to Plugin Manager, upgrade AnsiColor to 0.6.1 and restart Jenkins
• Build the job. Output: bold blue text

jl68 Thanks for the reproduction case. I think it would be handled by PR 147, which is ready to be merged and released, although I'm not sure when I'll have time to release the plugin.

I just released 0.6.2 with a change that should fix this issue for the cases I am aware of. If you are still seeing it after the upgrade, please copy-and-paste some of the broken output from Jenkins here (preferably replacing literal occurrences of the ASCII character 0x1b with the text 0x1b so we can see what is happening to the escape sequences).

As far I can see, it looks good now. Thanks for the fix!

Sorry for the delay. I had today time to test it again. And I still can see the control charcters.

After updating to 0.6.2, control character in /console and /consoleText:
^{[[0;32mok: [lxsrvmgi1360]}[[0m

After downgrading to 0.5.3, no control character in /console and /consoleText:
^{[[8mha:////4GByXBh6D5sO4uIaL/Xvo6rBHYkdqIOcMtgU7KVDnLnuAAAApR+LCAAAAAAAAP9b85aBtbiIQT2jNKU4P0+vIKc0PTOvWC8xrzgzOT8nv0gvODO3ICfVoyQ3xy+/JNU2Yj/Tagmf50wMjD4M7CWJ6SCJEgYhn6zEskT9nMS8dP3gkqLMvHTriiIGKaihyfl5xfk5qXrOEBpkDgMEMDIxMFQUlDDI2RQXJOYpFJdU5qTaKoEttlJQNjBwdjEwsFayAwAsE8VZpQAAAA==}[[0mok: [lxsrvmgi1360]^{[[8mha:////4MLkG6V+s9c4kbbINbBZTN8IdUcULVaJJVRaElSmS5VEAAAAkR+LCAAAAAAAAP9b85aBtbiIQT2jNKU4P0+vIKc0PTOvWC8xrzgzOT8nv0gvODO3ICfVoyQ3xy+/JNU2Yj/Tagmf50wMjD4M7CWJ6SCJEgYhn6zEskT9nMS8dP3gkqLMvHTriiIGKaihyfl5xfk5qXrOEBpkDgMEMDIxMFQUlDCw2+gXFyTm2QEAI9P8iI4AAAA=}[[0m

Note that for me, I am also still seeing the control characters in the console output but only while watching an active build. Inspecting the console output after a build has completed does render them correctly.

I am seeing the same behaviour as rverduijn.

I'm seeing the same behavior as rverduijn as well

I am also seeing the same issue with 0.6.2 version of plugin and CloudBees Jenkins Enterprise 2.164.3.2-rolling.

After refreshing the page colors appear. Issue only happens when you have opened console output before the {{ansiColor }}option is executed.

However, downgrading to 0.5.3, resolves the issue.
dnusbaum

eg.

[1;37;45m***************************************************************************** STAGE INIT *****************************************************************************

This seems similar to my issue with v0.6.2. This was working in v0.5.x I have a freestyle project where I have enabled ansi color with xterm. A single shell command with:

echo "testing-1.2.300" | grep -E --color=always '[0-9]+.[0-9]+.[0-9]+'

Results in:

I had the same issue with Jenkinsfile and ansible. The problem was I was using single quotes for multiline shell command, e.g.,

    sh '''
      . .venv/bin/activate
      molecule test
    '''

Switching to double quotes fixed the issue, e.g.,

     pipeline {
       ...
       options { 
         ansiColor('xterm') 
         ... 
       }
       stages {
         ...
         stage('Test') {
           steps { 
             sh """
                . .venv/bin/activate 
                molecule test 
             """ 
           }
         }
         ...
       }
     }

I can confirm this bug and also that downgrading to 0.5.3 (from http://updates.jenkins-ci.org/download/plugins/ansicolor/) helps.
 
My sh commands use double quotes (but only single-line, as in sh "bash path/to/script ${arg1} ${arg2}") already so I cannot confirm dhoer workaround.

With the 0.6.2 I get output similar to initialzero comment.

This issue is resolved as of 0.6.3

I concur that it is resolved as of 0.6.3. I do still see the terminal escape sequences in the console text output.

I see this issue has been reopened. In the 0.7.2 release the escape sequences are showing. For example, 

[1mPROCESSED

This issue must be related to a dependency. In the latest update to 0.7.2 I noticed the "[1mPROCESSED" issue in log files with Jenkins 2.235.5. However, I rolled back ansicolor to the last known working version which was 0.6.3 and this issue is still present.