Skip to content

Should CI environments infer ColorChoice::Always? #291

@woodruffw

Description

@woodruffw

Context: I was trying to figure out why CI environments (i.e. CI=true and similar) weren't being colorized by default when using anstream to plumb output containing ANSI colors. I ended up on this choice implementation:

#[cfg(feature = "auto")]
fn choice(raw: &dyn RawStream) -> ColorChoice {
let choice = ColorChoice::global();
match choice {
ColorChoice::Auto => {
let clicolor = anstyle_query::clicolor();
let clicolor_enabled = clicolor.unwrap_or(false);
let clicolor_disabled = !clicolor.unwrap_or(true);
if anstyle_query::no_color() {
ColorChoice::Never
} else if anstyle_query::clicolor_force() {
ColorChoice::Always
} else if clicolor_disabled {
ColorChoice::Never
} else if raw.is_terminal()
&& (anstyle_query::term_supports_color()
|| clicolor_enabled
|| anstyle_query::is_ci())
{
ColorChoice::Always
} else {
ColorChoice::Never
}
}
ColorChoice::AlwaysAnsi | ColorChoice::Always | ColorChoice::Never => choice,
}
}

If my read of that helper is right, the current logic only considers anstyle_query::is_ci() after raw.is_terminal() is satisfied. In practice that means that ColorChoice::Always branch won't be taken for CI environments, since (AFAIK) most CI environments don't actually provide a terminal (they support ANSI color codes, but they won't provide a true pty that would pass is is_terminal() check).

Given that, does it makes sense to split that check out, so that is_ci() becomes a sufficient condition for ColorChoice::Always? My intuition is "yes" (since the CI check seems to be a no-op as is), but there's also some nuance given that CI environments aren't real terminals and might only support a small subset of the escapes normally accepted by terminals (things like OSC codes in particular).

So, I don't have a super clear sense here, but I figured I'd open this in case others have a clearer picture than I do 😅. If this change makes sense, I'd be happy to send a PR for it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions