zarf command line execution error logging and log file readability

[brianrexrode]

Is your feature request related to a problem? Please describe.
When executing zarf package deploy from a command line, the erroring reporting seems inconsistent.
Example 1:
A deployment.yaml is missing spec.selector.
zarf output:

Example 2:
A deployment.yaml is missing spec.template.metadata
zarf output:

In both scenarios, when trying to review/troubleshoot using the associated log file with linux tools like vi, nano or simply cat the log file piped to less (cat /var/folders/bh/l8qqtz8x57j5vjd8sd33sxt40000gn/T/zarf-2022-10-12-08-46-18-3119412142.log | less) the log file is difficult to read due to the color flags.

Describe the solution you'd like
For example 1, similar logging output to example 2.
The ability to use basic linux tools to easily review and examine the log file for troubleshooting.

Describe alternatives you've considered
Manually testing yaml files before building a zarf package (i.e. kubectl apply -f deployment.yaml) to avoid the "WARNING Unable to complete helm chart install/update" messages and application deployment failure.
Don't currently have a good alternative to viewing the logs. I can investigate other editing tools.

Additional context
Add any other context or screenshots about the feature request here.

[jeff-mccoy]

That's interesting, cat on mac zsh (iterm / vscode) both print the color data as well, can you clarify what OS/terminal/shell you're using?

[brianrexrode]

Here's what I'm working with and yeah, I like to use bash instead of zsh but don't have a great reason why 😆

[Racer159]

In this case I believe the offender is less (I use bash as well but on popOS 22.04). Can you try with more @brianrexrode? (seems like less actually isn't more as they say).

less:

more:

[RothAndrew]

While there may be different tools that makes this better, I believe this is a good enough use case to push forward implementation of a '--no-color' flag (or something to that effect). Likely not super high priority, but this will definitely show up again, like in a CI pipeline where the choice of tool isn't very flexible

[jeff-mccoy]

Yeah we can probably look at that, but for FWIW, most CI systems do support ansi colors (I don't know of any that don't). I missed the fact he was using less, which I've always had issues messing up color output for me and prefer more. Also my CI flow is something like this when troubleshooting:

• Grab a debug tar output from the pipeline
• Extract the files
• cat longfileIcareabout (dragged into the terminal window from finder)
• terminal search

But I'm evil and like to use GUIs too...

[Racer159]

Linux would set you right @jeff-mccoy 😈

[jeff-mccoy]

I just like pretty things, I'm sorry I can't help it. I started using Linux in 1996 and used to live by a terminal only, but I guess I'm just too attracted to pretty interfaces...

[Racer159]

You should give the Gnome 40 series a shot sometime. GTK4 and libadwatia are starting to bring the shiny to linux now (though admittedly there are some rough edges still, particularly for phones (yes really https://blogs.gnome.org/shell-dev/2022/09/09/gnome-shell-on-mobile-an-update/) and tablets).

[brianrexrode]

I got the same results when using | more. I've probably done something weird to my terminal/shell. I'll try converting my profile back to zsh and see what I can find.

Thanks for looking into it.

[Racer159]

Reopening this issue since I think it is worth some docs on why we did this, and how to easily view Zarf logs.

[Racer159]

cc @Madeline-UX / @Jessy-Morris

[Racer159]

More context: https://kubernetes.slack.com/archives/C03BP9Z3CMA/p1677661784686499

[caesarshift]

pterm has a DisableColor function which (largely) resolves this issue. However, zarf prints some log lines before it parses the config which means that the initial log lines still print in color:

Lines with color even with this change:

 NOTE  Using config file /Users/jonsmith/git/zarf/zarf-config.toml

 NOTE  Saving log file to
       /var/folders/jl/q_sd6kxx74dg69cf00jgr2hr0000gn/T/zarf-2023-07-07-10-48-47-3648921497.log

OR with --no-log-file

 NOTE  Using config file /Users/jonsmith/git/zarf/zarf-config.toml

I'm not sure how or if to handle these log lines.