* Replace logConfig with zapcore.Core
* Add SyncFunc type and tests
* Change Sentry functions to accept a *sentry.Client
This allows the caller to do the error handling.
* Rename newCoreConfig to newCore
* Remove redundant WithCore option
* Update doc comments
This commit extends our logging wrapper code to allow the addition of automatically generated caller information to log entries. It also adds a way to selectively suppress this caller information for individual sinks. This commit does not change any of trufflehog's behavior - it just enables future functionality in case we want it to use it later.
This commit also provides an exportable type alias for sink configuration option functions so that callers have more flexibility in how they prepare groups of them.
This commit also adds some new tests for the existing redactionCore and fixes an existing bug in it. (The bug hasn't yet caused problems, but it created the potential for future problems.)
Counterintuitively, a new sink added to an existing logger will not inherit the existing logger's key-value pairs. This has only caused a problem in practice with respect to a small number of known key-value pairs, so this PR creates a way to add specific key-value pairs to new sinks.
This supersedes #4579.
Some source use client libraries that can emit errors that contain sensitive information - in particular, git-facing libraries that embed tokens into repository URLs. This PR introduces a way of redacting them - starting with GitLab (where we've seen this most recently), but in theory extensible to other sources as needed.
This implementation uses a custom zap core; this might also be possible with a custom zap encoder, but I didn't test it out.
(The deleted core.go file was entirely unused.)
* [THOG-643] Implement independent log level controls
There are two log level controls to mentally distinguish. Log levels
associated with a sink (e.g. stdout and streamed), and log levels
associated with a logger (e.g. a GitHub source).
The level is determined to be the minimum of the two. If a sink is at
level 0, then it will only output level 0 logs regardless of the
logger's level. This is best demonstrated by TestSinkWithName.
* Rename WithName to WithNamedLevel
* Check flush errors
* Replace IncreaseLevelCore with custom LevelCore
Adding a leveler that was less verbose would cause the initialization
fail, and therefore not be added to the core. This check is only at
the time of initialization.
An alternative approach to creating our own core is to set the child log
level equal to the parent, so initialization is guaranteed (with the
added benefit of intuitive behavior).
* Use controller if it exists, otherwise inherit parent's log level
* Cleanup some tests
Miccah
Cody Rose