Color output from CI jobs

GitLab supports color escape sequences when viewing a job’s output. Perhaps the same is true of GitHub, Jenkins, or other CI tools.

I’m guessing that the server running these commands is piping stdout and stderr to other processes or files which later get shipped over the wire. Because of this it is likely failing some isatty() call in _compat.py.

While it isn’t a tty, it will eventually be displayed by something capable of handling colors. My current workaround is to detect if it’s being ran as a GitLab CI job by the presence of an environment variable and explicitly setting ctx.color = True

I think this is something that could/should be handled internally by click so that I don’t have to add this workaround to every utility I write which may end up being used within some CI. Does anyone else agree?

workaround

#!/usr/bin/env python

import os

import click


@click.command()
@click.option('--name', '-n', default='Anonymous', envvar='LOGNAME')
@click.pass_context
def cli_main(ctx, name):
    if 'GITLAB_USER_LOGIN' in os.environ:
        ctx.color = True
    click.secho(f'Hello {name}', fg='magenta', bold=True)


if __name__ == '__main__':
    import sys
    cli_main(sys.argv[1:])

[flying-sheep]

Transcluding my comments from #558:

the chalk JS package has those 13 000 depending packages. this (transitively) includes nearly all node.js command line applications.

there’s no real standard for this. just check this mess

i think we have FORCE_COLOR, CLICOLOR, CLICOLOR_FORCE, LS_COLORS, GREP_COLORS, and various --color options, e.g. --color=always|auto|off in GNU tools. CLICOLOR[_FORCE] seems to be in cmake and OSX tools, as well as the most clear and intuitive way, but none of the bug reports for other libs had any impact. i’m sad for @jhasse for putting in so much work in PRs being interested, despite it being the best idea and already integrated in some tools.

convenient and expected would IMHO be to have a method that automatically adds a GNU-like --color option, as well as support for the whole env variable mess like supports-color does.

[eplodn]

I’m running aws-sam-cli that happens to use click to format its output, in Jenkins.

My Jenkins is perfectly capable of displaying colors, but click (correctly) discovers it’s not running with tty, so no colors would be printed.

My options are: a) forking aws-sam-cli and implementing the fix as above, while maintaining my fork, or b) respectfully ask the click maintainers to reconsider respecting an environment variable e.g. as per @flying-sheep 's proposal. It would still be up to me to run e.g. CLICOLOR_FORCE=1 aws-sam-cli ... in Jenkins.