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

Build output cached on CI plays back without color on machines where color is allowed #897

Closed
thebanjomatic opened this issue Mar 17, 2022 · 3 comments

Comments

@thebanjomatic
Copy link
Contributor

thebanjomatic commented Mar 17, 2022

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 the FORCE_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 the NO_COLOR environment variable, but it doesn't check the value, so NO_COLOR=0 is not the equivalent to force-enabling colors, and instead color.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.

declare -x NO_COLOR=1
yarn turbo run build --force

unset NO_COLOR
yarn turbo run build
@thebanjomatic
Copy link
Contributor Author

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.

@thebanjomatic
Copy link
Contributor Author

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?

thebanjomatic pushed a commit to thebanjomatic/turborepo that referenced this issue Apr 6, 2022
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)
@mehulkar
Copy link
Contributor

This is actually done now. Turbo only caches the raw logs now and the replay can be controlled at turbo run time now.

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

No branches or pull requests

2 participants