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

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

Krinkle created this task.Jun 3 2020, 9:59 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 3 2020, 9:59 PM

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

hashar added a subscriber: hashar.Jun 4 2020, 8:03 AM

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:

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.

hashar added a comment.Jun 4 2020, 8:22 AM

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

hashar closed this task as Resolved.Jun 5 2020, 7:51 AM

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