Refactoring of logging

[phillebaba]

Describe what should be investigated or refactored

Test week proved that certain functions are difficult because logging logic is tightly coupled with other logic. For example there are a couple of functions which will print formatted tables to a global logger instead of returning structured data and allowing the caller to deal with the output. Additionally there are a couple of places where errors are logged and exit is called instead of returning errors and allowing the called deal with them. We have also discovered that Pterm is not thread safe as documented in #2558 which causes more issues for unit testing.

For these reasons it has become apparent that some sort of refactoring of logging is required. A lot has happened since the initial implementation, like structured logging in standard lib. We need to define what logging is specific to the CLI and what is logging which is useful for those importing Zarf as a CLI. While it may complicate things we have to decide whether or not spinners and other "UI" elements should be used in any exported packages.

Links to any relevant code

https://github.com/defenseunicorns/zarf/blob/0c02643b9f5631a7bdd98650cc87c74901190771/src/pkg/utils/wait.go#L53
https://github.com/defenseunicorns/zarf/blob/0c02643b9f5631a7bdd98650cc87c74901190771/src/pkg/packager/common.go#L132

Additional context

We should split the work into a couple of steps to avoid creating a mega PR.

Tasks

• Add logger pkg
• Introduce --log-format flag and disable message when it's enabled.

Add logger lines alongside existing message lines

(Note, not all of these commands will have messages but they're here to ensure we check them all)

pkgr

• zarf package create
• zarf package deploy
• zarf package inspect
• zarf package list
• zarf package publish
• zarf package pull
• zarf package mirror-resources
• zarf package remove

init

• zarf init

connect

• zarf connect
• zarf connect list

destroy

• zarf destroy

dev

• zarf dev deploy
• zarf dev generate
• zarf dev find-images
• zarf dev lint
• zarf dev sha256sum
• zarf dev patch-git

Not needed

• zarf version
• zarf tools
• zarf completion
• zarf internal
• zarf dev generate-config

[phillebaba]

I realize that message fatal prints the debug stack when an error occurs which exits the program. Additionally some logs will differentiate between the message and the error. The error is only written to the debug logger which the message is written to the error writer.

Before removing this logic we need to determine if this is a feature required by end users.

[catsby]

Tangential to this, I recently refactored maru-runner's log levels and handling and I see the two projects share a sort of common ancestry (I think Maru borrowed heavily from Zarf).

I would suggest we refactor Zarf log levels to match the standard libraries log/slog package, although I see that unlike maru, zarf does not always wrap log/slog but I still think it's a good convention to follow. It should provide room for the custom log levels(?) that Zarf has like Note, which currently can't be filtered out with any log level flag. I can't tell if Note() is supposed to be a log level or not though, but it's in the same package an used similarly

[mkcp]

Edited the list of tasks at the top to instead list out the commands that have been ported over to slog, vs the ones that haven't.