-
Notifications
You must be signed in to change notification settings - Fork 173
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
c1d1d44
commit d91926b
Showing
1 changed file
with
26 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
# 25. Logging | ||
|
||
Date: 2024-06-06 | ||
|
||
## Status | ||
|
||
Proposed | ||
|
||
## Context | ||
|
||
Zarf is currently using an in-house built logging solution which in turn depends on pterm. This solution is used to output information to the end user who is using the Zarf CLI. This output is for the most part formatted with the purpose of look good for users of the CLI. Logging function calls are done both in the CLI specific code as well as in the packages. The logging is implemented in such a way that different levels exist with different impacts and log destinations. A common pattern that is used is to call `message.Fatal` whenever an error occurs. This will output the message to STDERR while writing the actual error message to a debug log and exit the program. Exiting the program in this manner makes unit testing difficult while also skipping proper context handling skipping any clean-up that was intended to run before exiting the program. | ||
|
||
## Decision | ||
|
||
I am proposing to completely refactor the logging functionality to follow a more standardized format using the newish slog interfaces. On top of that we would refactor the current internationalization by converting them to standardized errors. | ||
|
||
* Replace the message package with a slog interface. | ||
* Replace the lang package with static errors. | ||
* Remove any use of `message.Fatal` and instead return errors. | ||
* Refactor use of `message.WarnErr` to either return error or to log the error. | ||
* Relegate use of the spinner to CLI specific code. | ||
* Refactor existing functions that print formatted outputs to defer the printing to the CLI. | ||
|
||
## Consequences | ||
|
||
Refactoring the message package would make importing Zarf packages as a library simpler. It would also simplify any unit testing and debugging efforts by using predictable errors. The main downside is that some detail from logs will be lost especially when moving the spinner code out of any packages. Giving the same amount of detailed messages would be very difficult. We should take care to preserve the critical information while also decreasing the verbosity of logs at certain locations. |