Set the environment variable to enable colorful output by default

[Tyrrrz]

Description:

.NET previously disabled console colors if it detected that the output was redirected. Recently, a new environment variable has been added to override this: dotnet/runtime#47935

Setting below environment variables will enable colorful output when running on GitHub Actions (not on Windows though):

• DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION to 1 or true
• TERM to xterm

More info: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-environment-variables#dotnet_system_console_allow_ansi_color_redirection

Relevant discussion explaining the need for the second variable: dotnet/runtime#68302 (comment)

Justification:

Colorful output is much easier to visually parse and, since we can guarantee that we're always running on GitHub Actions (which supports ansi color escape codes), it makes sense to make this setting enabled by default. As the worst case, this should be at least added as one of the action inputs, but I think enabling it by default is the way to go (not anymore, read comments below).

Are you willing to submit a PR?

Sure

[vsafonkin]

Hi @Tyrrrz, we will take a look at this, thank you for your contribution!

[Tyrrrz]

Just as a note, we noticed that setting this variable manually on GitHub Actions still seems to not produce the expected color codes. It does work locally though. It's probably an issue with the dotnet CLI. 🤔

Here's the relevant discussion: dotnet/runtime#68302

Update: according to this comment, setting TERM: xterm is also required. Edited the original post.

[vsafonkin]

@Tyrrrz, it seems to me the setting of these variables is out of scope setup-dotnet action cause it's related to kind of customisation .NET installation but the goal of the action to install required .NET version with minimum custom configuration. It will be better the users will set these settings as workflow env variables from their side.

[Tyrrrz]

@Tyrrrz, it seems to me the setting of these variables is out of scope setup-dotnet action cause it's related to kind of customisation .NET installation but the goal of the action to install required .NET version with minimum custom configuration. It will be better the users will set these settings as workflow env variables from their side.

I understand your point, but here's why I think it makes sense as an addition to setup-dotnet:

1. Colored output looks much nicer without any drawbacks. I can't imagine a situation where a user may not want it.
2. The two environment variables (DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION and TERM) are used to convince dotnet that the output terminal/renderer supports color codes. This is always true in case with GitHub Actions.
3. Most users are not aware that this is an option that they can set at all. Putting it in setup-dotnet would guarantee that everyone gets it.

That said, there may be some edge-cases such as if some step relies on the output of a dotnet command to have a specific format (for example regex) that this option may break. Because of this, I now realize it's probably not a great idea to have it enabled by default in those cases (unless with a major version bump?).

In any case, I leave the decision with you :) I'm personally okay setting this manually for my own projects.

[timheuer]

Great suggestion @Tyrrrz! I'm in favor of this as well and brings this inline with some of the other colored output we see in Actions and other setup scripts as well (with node/etc). This seems like a small, but useful, thing to see in the unformatted log views. I think you identified a possible case (item 3 above) that could be a possibility, but could be easily gated with another input on the action (colored-output: false) but the majority of users win.

I'd love to see this in.

[vsafonkin]

cc @marko-zivic-93 @brcrista

[xt0rted]

...there may be some edge-cases such as if some step relies on the output of a dotnet command to have a specific format...

This is actually the case with FORCE_COLOR in node with the setup-node action (ref: actions/setup-node#317). When enabling that and using the cache option the post setup step fails because of the color codes in the log. The solution there is to disable that setting on the setup-node step, but it does catch you off guard if you don't know about it.

[xt0rted]

I've started to maintain a composite action that wraps this one and implements features that aren't yet supported. I just added this feature to it in case anyone's interested in trying it out. https://github.com/xt0rted/setup-dotnet

[vsafonkin]

I'm going to close this issue. More details in the PR: #293