-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Build output cached on CI plays back without color on machines where color is allowed #897
Comments
I'm willing to work on a PR for this, but wanted to get feedback before beginning since there are potentially different approaches to tackle this problem and I want to make sure the PR is aligned with the intended direction of the product. |
It looks like the decision to cache the colored + prefixed output directly was made for performance reasons in #462 but I'm not sure if this particular edge case of builds mixing and matching color and no-color output was fully considered as part of this change. @jaredpalmer would you be able to provide more context since you made that change? |
This change checks for --color / --no-color as command-line arguments as a mechanism for forcing color in non-TTY situations, or forcing --no-color for TTY. Additionally, this change hooks into the FORCED_COLOR environment variable that is used by the [`supports-color` npm package](https://www.npmjs.com/package/supports-color) that is used by a variety of packages in the node ecosystem. The intention of this PR is to alleviate some of the concerns from Issue vercel#897 by allowing users of turborepo to enable color output on CI runners such as Github Actions which support color output (as mentioned in the [fatih/color documentation](https://github.com/fatih/color/tree/master#github-actions)). With github actions and local builds are both running in color, then the cached output should be consistently in color, compared to the current situation where its a mix of color and non-color output with a remote shared between CI and users building interactively. The FORCED_COLOR environment variable is something that I find myself already setting when running turbo so that the streamed output is in color for the build and testing tools that I am running with it, so it seemed like a natural way to provide this argument without needing to modify the CLI parameters being passed to turbo. In the event multiple methods are being used, the precedence is: * isTTY or not (provided by fatih/color) * $NO_COLOR (if set, then color is disabled) * $FORCED_COLOR ("1", "2", "3", "true" will enable color, "0", or "false" will disable color) * --color/--no-color (the last argument wins if both exist)
This is actually done now. Turbo only caches the raw logs now and the replay can be controlled at |
What version of Turborepo are you using?
1.1.6
What package manager are you using / does the bug impact?
Yarn v2/v3
What operating system are you using?
Windows
Describe the Bug
It looks like currently the console output log contains the entire line that gets printed to the console including the
package_name:task:
prefix. Generally this is ok, but the behavior is a bit weird when you cache a build on CI or in an environment where color is disabled, and then play it back in an environment where color is allowed since you will get a mix of colored / and uncolored lines in the resulting output depending on which packages were hits/misses.Expected Behavior
I was kind of surprised that turbo doesn't just cache the raw program output, and then add the prefix back in when playing it back. This would allow the decision of whether or not to use color output to be made at the time it is being displayed instead of committing to the value at the time the build was run.
Separate from that, a different approach might be a
--color
/--no-color
flag, or checking theFORCE_COLOR
environment variable to allow you to enable color output in github actions. This way the output will be cached with color when running on CI instead of just plain text. (Note:github.com/fatih/color
does use theNO_COLOR
environment variable, but it doesn't check the value, so NO_COLOR=0 is not the equivalent to force-enabling colors, and insteadcolor.NoColor = false
must be set programmatically.To Reproduce
This can be reproduced with local builds by using the NO_COLOR environment variable to disable colors for one build run, and then play it back.
The text was updated successfully, but these errors were encountered: