Fixed --no-color flag behaviour in non-tty environments

[Prashansa-K]

This fixes issue #1313 and makes the flag behaviour consistent across tty and non-tty.

The attached image shows the changed behaviour.
Now, the non-tty output also comes up as colored by default, same as tty output. This can be overridden by passing the --no-color flag.

I have a doubt though.
If our customers pass the deck output to a non-tty (may be a file), this can cause things to break if --no-color is not passed, as the colorised output may cause formatting issues in a file.
Is this doubt valid?
Should I check for non-tty environments separately and handle this, if this is indeed a valid usecase?
@GGabriele @mheap

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Project coverage is 22.39%. Comparing base (200a471) to head (ded0121).

Files	Patch %	Lines
cmd/root.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1339      +/-   ##
==========================================
- Coverage   22.39%   22.39%   -0.01%     
==========================================
  Files          54       54              
  Lines        4514     4515       +1     
==========================================
  Hits         1011     1011              
- Misses       3403     3404       +1     
  Partials      100      100              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[GGabriele]

If our customers pass the deck output to a non-tty (may be a file), this can cause things to break if --no-color is not passed, as the colorised output may cause formatting issues in a file.
Is this doubt valid?

I'd worried only if this commit changes the default behaviour of the tool. Is it the case?

Should I check for non-tty environments separately and handle this, if this is indeed a valid usecase?

I'd let @mheap chime in, but I believe predictability is a very important feature. I'd vote against doing special handling on a case-by-case way since we should let the input define the expected behaviour.

===

On a side note: please check here for the convention we use for commit messages. This will help us have a consistent and clear "git story".

Thanks!

[mheap]

This does change the default behaviour. The expected behaviour from the issue is as follows:

• Default: TTY gets colour, non-TTY doesn't
• --no-color=true: Both TTY and non-TTY don't get colour
• --no-color=false: Both TTY and non-TTY get colour

There may not be a way to differentiate --no-color=false from the default.If so, how would you recommend explicitly enabling colours without changing the default behaviour?

[Prashansa-K]

For retaining the default behaviour, I can check if the flag was passed or not before changing the value for color.NoColor.
Submitted the new change with commit message as per conventions.

[GGabriele]

I didn't know about viper.IsSet, nice!!

Good job!