Escape chars printed raw in partial console output since 0.7.0

[salavessa]

Escape chars printed raw in partial console output since 0.7.0 (works ok in 0.6.3)

Test environment

• Jenkins Version: 2.222.3
• AnsiColor Version: 0.7.0
• Hostsystem: Linux x64

Expected behavior

I would expect the colors/format to appear correctly when/if Jenkins console truncates long output (/console) and not only when the full output is displayed (/consoleFull).

Actual behavior

The escape sequences are printed raw on truncated console output.

[clicking Full Log link displays the expected behavior]

Steps to reproduce the behavior

Any output that colorizes the output and is truncated by jenkins console doesn't seem to be working as expected.

[tszmytka]

Thank you for the report. I had a lot of trouble trying to reproduce this.

Turns out this happens for Jenkins instances which never had a default, global ansicolor options set. My test box had (even if they are all re-set to defaults now) and this prevented me from encountering the bug.

This means that a dirty, short-term solution is to set a global color map and then immediately remove it.

I don't have much free time at the moment but will try to come up with a permanent fix in the coming days.

[salavessa]

The wokaround worked like a charm, thanks for that!
Maybe it would be worth to document it somewhere ("known issues") while the permanent fix isn't put in place.
Feel free to close this issue if you believe there's no point for it to be open.

[twz123]

Turns out this happens for Jenkins instances which never had a default, global ansicolor options set. My test box had (even if they are all re-set to defaults now) and this prevented me from encountering the bug.

For those of you which use Configuration as Code to manage Jenkins, here's the config snippet that enables the global color map:

unclassified:
  ansiColorBuildWrapper:
    globalColorMapName: "xterm"

Maybe setting the global color map name to the empty string will also fix the problem.

[muppet3000]

We're seeing a variant of this issue on our Cloud Based Jenkins instances (latest LTS of Jenkins and 0.7.1 of this plugin, entirely deployed using Helm and the JCASC plugin).
If we revert to 0.6.3 the problem goes away.
However, we're seeing this affect all of our console output, not just the shortened console log. Also, if we set the default value to "xterm" it all renders correctly instantly. However, if we subsequently remove that option it will immediately go back to only rendering the escape characters (as a backwards facing arrow).

We have a mixture of JNLP and Swarm based agents, interestingly any jobs running on the Swarm agents do not suffer this problem at all, however, when a job is run on a JNLP agent it always has this issue.

I'm unsure how related our issues are to this ticket, however it feels like we're suffering the same symptoms at the very least, and they're fixed by the same workaround. Therefore, I hope that they're fixed by the same fix.

As and when there's a release candidate for testing please can you add a link to it here and we'll be happy to test.

Unsure how related to this: https://issues.jenkins-ci.org/browse/JENKINS-55139 this issue is, thought it was worth the tag though.

[tszmytka]

@muppet3000
Thanks for a detailed description. Having dealt with a fair share of doesn't work for me comments I really appreciate it.

However, we're seeing this affect all of our console output, not just the shortened console log

This ticket is specifically about truncated vs. full log.

Also, if we set the default value to "xterm" it all renders correctly instantly. However, if we subsequently remove that option it will immediately go back to only rendering the escape characters (as a backwards facing arrow).

This seems like the correct behavior to me. Why would you expect ansicolor to work if you remove the "global color map"? Are you instructing ansicolor to run in your pipeline then? If so - please post an example.

The "global color map" setting is for a situation where you already have a bunch of pipelines (or old-fashioned jobs) which do not trigger ansicolor on their own and you want to enable it for all of them in one go. If you then remove the global color map they go back to not interpreting ansi escape characters in any way.

[muppet3000]

@twz123 Thanks for the response.

I omitted the part where we're invoking ansicolor using the scripted pipeline syntax so our code looks something like this:

node('jnlp') {
  ansiColor('xterm') {
    sh """
      ./script_that_outputs_escape_chars.sh
    """
  }
}

If I change the node to be one of our swarm nodes then it works fine.

[tszmytka]

@muppet3000 In order to be able to reproduce this could you please: 1. Post the exact version of the `jnlp` image you are using. 2. Are you using `timestamper` in any form? In the pipeline or through its global settings (similar to `ansicolor`). 3. Is this **the whole** pipeline that causes this behavior? If not please post a full one. Problems often arise from a combination of plugins/settings that no one managed to test before preparing new version.

…

On Tue, Jul 21, 2020, 22:39 muppet3000 ***@***.***> wrote: @twz123 <https://github.com/twz123> Thanks for the response. I omitted the part where we're invoking ansicolor using the scripted pipeline syntax so our code looks something like this: node('jnlp') { ansiColor('xterm') { sh """ ./script_that_outputs_escape_chars.sh """ } } If I change the node to be one of our swarm nodes then it works fine. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#185 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQGV4IOFO6HMTUXS2KQZPDR4X4H7ANCNFSM4NKI4F4A> .

[muppet3000]

1. Post the exact version of the jnlp image you are using.

jenkinsci/jnlp-slave:4.0.1-1

2. Are you using timestamper in any form? In the pipeline or through its global settings (similar to ansicolor).

We have it installed but it is not used in the pipeline and does not have the "Enabled for all pipeline builds" option ticked in the settings

3. Is this the whole pipeline that causes this behavior? If not please post a full one. Problems often arise from a combination of plugins/settings that no one managed to test before preparing new version.

No, it was just something I knocked together last night, I was able to reproduce the issue using the following pipeline though:

/* #################################
*     START OF MAIN PIPELINE
* ##################################*/
//This doesn't work ('docker') is a label provided by our kubernetes pods running the jnlp container
node('docker') {
  try {
    ansiColor('xterm'){
      cleanWs()
      checkout scm
      stage('Test JNLP') {
        sh(returnStatus: true, script: """
          env
          pwd
          ls -l
          ./ansi_test.sh
        """)
      }
    }
  } catch (e) {
    currentBuild.result='FAILED'
    throw e
  } finally {
    //Steps that will always be run
  }
}

//This works
node('swarm') {
  try {
    ansiColor('xterm'){
      cleanWs()
      checkout scm
      stage('Test Swarm') {
        sh(returnStatus: true, script: """
          env
          pwd
          ls -l
          ./ansi_test.sh
        """)
      }
    }
  } catch (e) {
    currentBuild.result='FAILED'
    throw e
  } finally {
    //Steps that will always be run
  }
}

The ansi_test.sh script contains the following (from your README file):

#!/bin/bash

printf "\e[31mHello World\e[0m\n"
printf "Normal \e[1mBold\e[0m\n"
printf "Normal \e[4mUnderlined\e[0m\n"

[tszmytka]

I've run a slightly-adjusted (for simplicity) version of your pipeline

node('jnlp-slave-4.0.1-1') {
  try {
    ansiColor('xterm') {
      cleanWs()
      stage('Test JNLP') {
        sh(returnStatus: true, script: """
          pwd
          ls -l
          printf '\\e[31mHello World\\e[0m\n'
          printf 'Normal \\e[1mBold\\e[0m\n'
          printf 'Normal \\e[4mUnderlined\\e[0m\n'
        """)
      }
    }
  } catch (e) {
    currentBuild.result='FAILED'
    throw e
  } finally {
    //Steps that will always be run
  }
}

against the following configurations:

• ansicolor v0.6.3 + jenkinsci/jnlp-slave:4.0.1-1
• ansicolor v0.7.1 + jenkinsci/jnlp-slave:4.0.1-1
• ansicolor v0.7.1 + jenkinsci/jnlp-slave:4.0.1-1 + timestamper "Enabled for all Pipeline builds" ticked

All of them produced the exact same, correct output.

@muppet3000
Could you please create a new pipeline job, copy-paste the above pipeline, change node identifier to docker, run it and post the result screenshot?
What would be also very helpful is the raw log file. If you have access to Jenkins' shell it should be located at:

<jenkins-home>/jobs/<name-of-your-job>/builds/<last-build-no>/log