Just for the context. GitHub Actions has broken TTY detection. CI supports colors, but report lack of TTY.

But I am not sure about the best solution here.

I see now. Upstream issue is here. I'd like to have color on a test script on GH Actions too, I just don't want color on every child process that it starts and internally reads the output of.

$ node -e "console.log(require('picocolors').isColorSupported)" | cat
false
$ CI=1 node -e "console.log(require('picocolors').isColorSupported)" | cat
true

Other CI services that also set $CI might not even support colours, but they'd be enabled anyway and the tests would fail. It would be really confusing trying to understand what's going on, because the CI might just show something like "OK" is not equal to "OK".

I think we should either;

• Leave users to work around their chosen CI system's bugs themselves, instead of forcing them to work around our workaround of a bug in a specific CI system that they might not even be using, or
• Find some way to cheaply but reliably detect Github Actions, so we can turn colours on for it without relying solely on the $CI variable.

Find some way to cheaply but reliably detect Github Actions

Oh. $GITHUB_ACTIONS is always set to true on Github Actions. 🎉

I worked around this by using supports-color, which is smallish at 10kB unpacked, 0 deps, and detects colour support correctly in a whole lot of environments including silly ones like GH Actions.

We're experiencing this too, see netlify/cli#4354 (comment) in case a reproduction is needed.