False-negative on GitHub Actions about supports-color HOT 22 CLOSED

I think this can be closed, as it's fixed with v7.2

from supports-color.

Seems like we should call @chrispat here

from supports-color.

@Qix- from what I can tell, this not solved yet:

In the code, this check:

	if (haveStream && !streamIsTTY && forceColor === undefined) {
		return 0;
	}

comes before this part:

	if ('CI' in env) {
      // etc...

When run on GitHub Actions, the first condition already returns 0. This is because of this open issue in the runner: actions/runner#241

As a result of this, chalk does use color in my action. I'd be happy to work out a reproducing example if anyone's interested, but it looks kind of obvious to me given the evidence above.

from supports-color.

Hey @ai :) Do you have an example I could take a look at? Chalk behaves differently based on how it's used (e.g. with pipes). Can't confirm if this is a bug or not without seeing if there's another issue.

from supports-color.

Sure, here is an example with FORCE_COLOR=2.

I have Node.js script with simple code like:

#!/usr/bin/env node

import chalk from 'chalk'

process.stdout.write(chalk.red('Test'))

When I run this script in CI with:

      - name: Deploy files
        run: ./script.js

I have no colors and I start to have colors only with:

      - name: Deploy files
        run: ./script.js
        env:
          FORCE_COLOR: 2

from supports-color.

Which version of chalk? chalk@3 uses [email protected] which includes #102, so this should be working.

Can you verify you're at chalk >= 3.0?

from supports-color.

"chalk": "^3.0.0",

I checked that I have GITHUB_ACTIONS env.

Maybe some other check disable it?

from supports-color.

Very strange. Could you see if process.stdout.isTTY is truthey?

from supports-color.

process.stdout.isTTY is undefined: https://github.com/logux/logux.io/commit/6392d1a99a61710b8a5e5f08e36a2796ea689ff5/checks?check_suite_id=379405498

from supports-color.

That's why. For whatever reason, Node doesn't seem to think it's outputting to a TTY. This is probably on Github not setting up a proper pseudo terminal environment for actions to run in.

Unfortunately, there's no great way to properly solve this without Github's help. The environment checks have to come after the TTY checks, otherwise we'd break people piping output to other programs (which would get polluted with escape sequences).

Unless we think Github can fix this with PTY support, unfortunately this is a nofix - FORCE_COLOR=1/=2 will have to be used instead.

Sorry about that :/ Wish I had a better answer.

If a member of the Github staff wants to answer, I'll happily re-open this.

from supports-color.

Took the liberty of contacting Github about it. If they respond positively, I'll open this back up and track it ^^

Thanks for bringing it to our attention!

from supports-color.

I also created an issue (hope I used right place for it) actions/runner-images#218

Thanks for finding the actual reason.

from supports-color.

Re-opening for visibility, then :)

from supports-color.

Can we just force colors on GITHUB_ACTIONS even without isTTY since we know that GH supports colors?

from supports-color.

You can, sure. But as a general rule, no. It would break anyone using pipes.

from supports-color.

Oh, I forgot about pipes

from supports-color.

Solved with https://github.blog/changelog/2020-04-15-github-actions-sets-the-ci-environment-variable-to-true/? Maybe not if it's tty detection that's off 😀

from supports-color.

This should be fixed in 651576a

A new release should be great.

from supports-color.

Yep, thanks for the reminder. Let me know if this isn't solved by upgrading.

from supports-color.

Does anyone have this working? We're also seeing level 0 returned due to isTTY being undefined.

As @rethab said, this seems to be an issue on GitHub's side - but given it has been so long, perhaps a workaround can be implemented here?

from supports-color.

As mentioned at the top @mrmckeb FORCE_COLOR=2 works. See for example my PR here:
https://github.com/openstreetmap/iD/pull/9692/files

Or any of the others referencing this issue and linked to it.

from supports-color.

That's a great solution, thanks. I was wondering if anyone had a solution that end-users wouldn't need to implement though.

For now, I've implemented this:

if (env.GITHUB_ACTIONS) {
  const supportsColor = createSupportsColor({ isTTY: true });
  if (supportsColor) {
    chalk.level = supportsColor.level;
  }
}

from supports-color.