Test output colors not applied if output is too long

[davidrapin]

We are using Strider v1.9.4

When the output of our tests is too long (2107 lines) the coloring stops working:

When the output is shorter (~100 lines) the coloring works great (same output but stops before because of test failure):

[oliversalzburg]

That is by design as performance suffers greatly when trying to parse ANSI coloring in long outputs

[knownasilya]

Any way we could parse out the extra characters introduced once that limit is reached so that readability doesn't suffer?

[davidrapin]

@oliversalzburg thanks for the answer, could you let me know what the limit is?
Would you consider making this limit customizable via the configuration file?

@knownasilya the optimal behavior would actually be:

1. string.length  is smaller or equal to limit:

return ainsi2html(string)

2. string.length is greater than limit:

return ainsi2html(string.slice(0, limit)) + stripcolorcodes(string.slice(limit))

see https://www.npmjs.com/package/stripcolorcodes

[oliversalzburg]

For reference https://github.com/Strider-CD/strider/blob/master/client/ansi/filters/ansi.js#L8

As the output is streamed to the client, the rendering is performed on the client side.

As long as performance is not negatively impacted, I would accept any change in this area :)

[oliversalzburg]

Sorry for the few words, but I was on the road.

I originally implemented this "fix" because there were major performance issues in this area. For some builds it was nearly impossible to be even able to open them without the browser freezing/crashing.

I admit that the fix is horrible, but it does actually fix the issue without creating a new issue that could appear when trying to remove control codes or rendering them another way.

If someone would be able to provide a better fix for this, I would be very happy. Being able to control this behavior would also be nice, then people could decide on their own what's best for them. This could be a nice change that takes not too much effort.

[davidrapin]

@oliversalzburg If you reopen the bug, we'd be happy to contribute a PR 😉

[oliversalzburg]

The PR would go into a separate ticket anyway, but, sure :)