Skip to content

Commit

Permalink
feat: refactor logging
Browse files Browse the repository at this point in the history
  • Loading branch information
phillebaba committed Jun 7, 2024
1 parent c1d1d44 commit d91926b
Showing 1 changed file with 26 additions and 0 deletions.
26 changes: 26 additions & 0 deletions adr/0025-logging.md
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.

0 comments on commit d91926b

Please sign in to comment.