Closed Sebelino closed 1 year ago
This appears to be related to https://github.com/fatih/color/issues/132.
I can think of three solutions:
color.NoColor = false
unconditionally. However, this would mess up output resulting from piping operations.--output-format
parameter. However, depending on one's needs, this might warrant a combinatorial explosion of supported values for this parameter (human-nocolor
, ci-nocolor
, sarif-nocolor
...).--color
parameter with the values auto
, always
and never
, similar to how ls --color
works. This seems to me to be the most flexible solution, though it requires introducing a new optional parameter.Hej @Sebelino! 👋
Hmmmm, that's annoying, I would have expected faith/color to be smarter here. I think that I like option 3 the best, maybe in some sort of combination with automatic detection if we're running inside GitHub Actions.
I've pushed a hacky fix with auto coloring support that enables color support by default when running on GitHub Actions. Are you building from source, or should I make a new release so that you can test it?
Hoy, that was quick! I built it from source and it works beautifully now. Didn't even have to supply the --color
flag, although it's still a nice-to-have feature.
Thanks!
No problem! :-)
Which version of kube-score are you using?
kube-score
version: 1.16.1What did you do?
Within a Github Actions job, run
kube-score score
on any YAML file that causeskube-score
to produce output.What did you expect to see?
The output from
kube-score
in the Github Actions job should be colored, like when I runkube-score
locally.[CRITICAL]
lines should be red,[OK]
lines should be yellow, etc.What did you see instead?
The output is not colored: