Page MenuHomePhabricator

ASCI escape codes shown literally in Jenkins build output
Closed, ResolvedPublic

Description

When a developer finds a failing build (example commit, example build), they currently read the following:

00:00:53.914 /src/modules/ext.eventLogging/core.js
00:00:53.914   [2m117:error  Identifier 'client_dt' is not in camel case  [2mcamel
00:00:53.914   [2m366:error  Identifier 'client_dt' is not in camel case  [2mcamel

Screenshot 2020-06-03 at 22.59.05.png (220×1 px, 62 KB)

The colors are still recognised and activated, but there are also garbage escape sequences printed out, which is rather confusing to users. In particular because it makes it difficult to tell what is what. E.g. 117 above is a linr number, and camel is the eslint rule ID, which would need to be used to disable the rule inside the patch.

This is a regression, but it may've been weeks or months by now. Sorry for not noticing it earlier.

Event Timeline

We're currently running 0.6.3; if 0.7.1 with the fix gets released soon, upgrading isn't hard.

I had the plugin updated on May 6th from 0.6.2 to 0.6.3 T233688


That seems to be for PR 176 which has been released in 0.7.0.


From the Jenkins raw console log viewed with vim:

That seems to be a follow up fix for [[ https://github.com/jenkinsci/ansicolor-plugin/pull/176 | PR 176 ]] which went in 0.7.0.
^[[0m  ^[[2m117:11^[[22m  ^[[31merror^[[39m  Identifier 'client_dt' is not in camel case  ^[[2mcamelcase^[[22m^[[0m
^[[0m  ^[[2m366:13^[[22m  ^[[31merror^[[39m  Identifier 'client_dt' is not in camel case  ^[[2mcamelcase^[[22m^[[0m
^[[0m^[[0m
^[[0m^[[31m^[[1m✖ 2 problems (2 errors, 0 warnings)^[[22m^[[39m^[[0m
^[[0m^[[31m^[[1m^[[22m^[[39m^[[0m
Warning: Task "eslint:all" failed.^G Use --force to continue.

Aborted due to warnings.

Which is rendered by less -R as:

eslintansi.png (121×728 px, 17 KB)

Looks like the plugin does not properly recognizes the sgr sequence ^[[2m which is:

ESC[ 2 m is the sgr to decrease the intensity of the text (see list at https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_parameters). It is not recognized by the 0.6.3 plugin.

That is implemented by PR #173 sgr effect normal intensity, the associated issue shows examples coming from javascript related tooling.

src/main/java/hudson/plugins/ansicolor/AnsiHtmlOutputStream.java
case ATTRIBUTE_INTENSITY_FAINT:
    final AnsiAttributeElement faint = AnsiAttributeElement.faint();
    closeTagOfType(faint.ansiAttrType);
    openTag(faint);
    break;
src/main/java/hudson/plugins/ansicolor/AnsiAttributeElement.java
public static AnsiAttributeElement faint() {
    return new AnsiAttributeElement(AnsiAttributeElement.AnsiAttrType.FAINT, "span", "style=\"font-weight: lighter;\"");
}

The PR has been released with 0.7.0.

From stylelint 7.6.0 changelog:

Fixed: the string and verbose formatters now use dim instead of gray for greater compatibility with different terminal color schemes.

The reason is to not hardcode the color and thus work on different color schemes (for example one having a gray background).

https://github.com/stylelint/stylelint/pull/2003 / https://github.com/stylelint/stylelint/issues/1996

Munkunda pointed to https://github.com/jenkinsci/ansicolor-plugin/issues/186 which is a fix for some 256 colors output. We might have output generating such codes which would end up broken by 0.7.0, in this case we have to wait for a 0.7.1. If that stylelint issue from this change is a big concern, we can upgrade to 0.7.0 right now ;)

Mentioned in SAL (#wikimedia-releng) [2020-06-05T07:45:34Z] <hashar> jenkins: upgrading ansicolor plugin 0.6.3 > 0.7.0 # T254408

I have looked at the given build and the dim ansi sequence seems good now:

ansiok.png (169×750 px, 18 KB)