Closed wyardley closed 1 year ago
@yannh you have any thoughts about accepting something like this (and if so, how it should be implemented)?
Hi @wyardley , to be honest, I am on the fence - it adds a dependency, and lines of code, for a really small cosmetic improvement... I believe most people run kubeconform in continuous integration systems, do CI systems even support colours? :thinking: Maybe if more people vouch for this and explain how this would be used and how this would be better?
Hi - Totally get it, and would be happy to implement it with fatih/color
(or even raw control codes) to reduce the dependency overhead, as after putting this PR in, it became very clear how heavy aurora
is for a use case like this.
And, while sometimes it is possible to go overboard with fancy colors / fonts / etc. (or even do things that cause issues for people where those control codes aren't supported), I do think it helps parse the output more easily (esp. with things like warnings about skipped checks, which can sometimes be easy to miss with kubeconform
, esp when missing schemas are ignored).
FWIW, Circle, Travis, and (I think) GHA all will render terminal colors, though not necessarily extended colors beyond the typical 16. My use case is in CI - in fact, with one specific pipeline that checks a lot of kube configs, I actually adapted tapview
to take the tap output and format it a bit, and then Python pygmentize (with an additional custom formatter) to colorize the output, but it's proving less practical to do that in cases where I'm running kubeconform
in a lot of separate projects.
Here's how that looks inside a CircleCI run (in this case, the successful tests just show a small green dot, sort of the way rspec / mocha do it, but errors or skipped checks would show up in bigger
Here's an example with some failures (the "ok" for the skipped one is a byproduct of how tap output works, but still shows up with an orange 'skip' on the right).
The idea here would be to build in some degree of support for similar formatting directly into this new report format.
I can make a separate issue for this, but one thing I noticed is that the logic when Name
or Kind
is missing sometimes has some gaps. Not sure if it would make sense to centralize the logic of printing out the error in those cases?
You've nearly convinced me :) I'll give this a shot soon, thanks a lot for your patience :pray:
You've nearly convinced me :) I'll give this a shot soon, thanks a lot for your patience 🙏
If the goal is to keep it really simple, either the other module mentioned above, or embedding raw control codes might do the trick.
I was also on the fence about making it a flag / env var for the regular console output, or a new / separate output format, though being able to have the little utf-8 characters on the left showing the status is maybe an argument for a separate format (maybe some functions could be shared between the two though?)
Check out this branch, let me know if you're happy with the colors? I removed the dependency on Aurora and fixed tests https://github.com/yannh/kubeconform/pull/195
Looks good to me!
Merged :rocket:
Add a new output format "pretty", which adds colorized output (also includes https://pkg.go.dev/github.com/logrusorgru/aurora vendored in; could also do this in a lower tech / fewer deps way if you prefer (or look at something like https://github.com/fatih/color, which might be smaller).
Here's how it looks currently:
This is still a WIP. Not sure how to get tests working again, because of how output is currently being returned, so appreciate any suggestions there.
If this is approved in concept, we could also talk about doing some / all of the following.
short term: