Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test output colors not applied if output is too long #999

Open
davidrapin opened this issue Oct 7, 2016 · 7 comments
Open

Test output colors not applied if output is too long #999

davidrapin opened this issue Oct 7, 2016 · 7 comments

Comments

@davidrapin
Copy link

We are using Strider v1.9.4

When the output of our tests is too long (2107 lines) the coloring stops working:
screen shot 2016-10-07 at 11 25 47

When the output is shorter (~100 lines) the coloring works great (same output but stops before because of test failure):
screen shot 2016-10-07 at 11 28 45

@oliversalzburg
Copy link
Member

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

@knownasilya
Copy link
Member

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

@davidrapin
Copy link
Author

@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)
  1. string.length is greater than limit:
return ainsi2html(string.slice(0, limit)) + stripcolorcodes(string.slice(limit))

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

@oliversalzburg
Copy link
Member

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
Copy link
Member

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
Copy link
Author

davidrapin commented Oct 10, 2016

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

@oliversalzburg
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants