False-negative on GitHub Actions #106

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.

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

Which version of chalk? chalk@3 uses supports-color@7.1.0 which includes #102, so this should be working.

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

"chalk": "^3.0.0",

I checked that I have GITHUB_ACTIONS env.

Maybe some other check disable it?

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

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

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.

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!

Seems like we should call @chrispat here

I also created an issue (hope I used right place for it) https://github.com/actions/virtual-environments/issues/218

Thanks for finding the actual reason.

Re-opening for visibility, then :)

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

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

Oh, I forgot about pipes

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 😀

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

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

@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: https://github.com/actions/runner/issues/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.

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?

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.

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;
  }
}