Enable console color output by default

[vsafonkin]

Description:
Set environment variables DOTNET_SYSTEM_CONSOLE_ALLOW_ANSI_COLOR_REDIRECTION and TERM to enable color output by default.

Build via current setup-dotnet: https://github.com/vsafonkin/dotnet-setup-test/actions/runs/2265449492

Build via setup-dotnet from PR branch: https://github.com/vsafonkin/dotnet-setup-test/runs/6278013678

Related issue:
#288

Check list:

• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[xt0rted]

I ran into issues doing this in node when setting FORCE_COLOR where problem matchers stop working due to the color codes being emitted in the logs (the setup-node cache feature also stops working and returns an error). An example of this was found with my stylelint problem matcher and I had to work around it with a much more complex regex xt0rted/stylelint-problem-matcher#361 (demo run with it). I haven't tested the .net problem matcher yet to know how that works, but it's something to keep in mind when adding this in I think.

[vsafonkin]

I ran into issues doing this in node when setting FORCE_COLOR where problem matchers stop working due to the color codes being emitted in the logs (the setup-node cache feature also stops working and returns an error). An example of this was found with my stylelint problem matcher and I had to work around it with a much more complex regex xt0rted/stylelint-problem-matcher#361 (demo run with it). I haven't tested the .net problem matcher yet to know how that works, but it's something to keep in mind when adding this in I think.

Hey @xt0rted, thank you for your help. I've tested the problem matcher which is defined in setup-dotnet for simple case (incorrect .NET version) and looks like the matcher works fine for this case: https://github.com/vsafonkin/dotnet-setup-test/actions/runs/2269399181

Also looks like the cache action works fine with enabled colorful output for .NET, at least I didn't face with any issues for caching. But you're right, my custom problem matcher stopped working after colorful output was enabled. It requires to change the custom problem matcher regex more complex.

In this case, I'm afraid the colorful output by default can break a part of customers who use their custom matchers. Probably, we should refuse these changes and close this PR.

cc: @marko-zivic-93 @brcrista

[brcrista]

@vsafonkin thanks for the investigation. Just to make sure I understand, is the issue that ANSI color codes are interfering with problem matcher regexes?

[vsafonkin]

@vsafonkin thanks for the investigation. Just to make sure I understand, is the issue that ANSI color codes are interfering with problem matcher regexes?

@brcrista, exactly, if someone uses setup-dotnet action and own problem matcher it can be broken after we enable colorful output, or rather the problem matcher will not detect problems that the customer wants to see.

[brcrista]

Ok. So in the spirit of "yes, and" ... to ship this we would need to

1. Release a new major version of the action
2. Provide some official support for problem matching with ANSI color codes. Maybe something in actions/toolkit?

But yes, in the short term I think we'll just close this.

[vsafonkin]

But yes, in the short term I think we'll just close this.

I agree, I believe the customers can set these env variables from their side if they need it and it will be safer for them.