-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Logger not correctly applying named config #696
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #696 +/- ##
===========================================
+ Coverage 57.24% 57.42% +0.18%
===========================================
Files 143 143
Lines 16393 16396 +3
===========================================
+ Hits 9384 9416 +32
+ Misses 6127 6098 -29
Partials 882 882
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and seems to work as expected. Thanks for fixing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
suggestion: additionally support Lines 145 to 167 in 2e378dd
|
8d76845
to
27aa302
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a bug in the sourcenetwork#658 that got merged which effectively broke the entire feature. Tests didn't catch it as they were accidentally poorly defined, as they would pass with the default logger settings as well as the custom ones set in the test. There are two fixes in this PR that resolves the problem. During review, we decided to switch back the Config.Log from Config.Logger, but the viper Bind calls were still using Bind(logger.loglevel) (old name). Additionally, the validate call on the config.Log struct previously always returned nil (no errors), but was changed recently to validate the available options. But, if the --loglevel option is provided it will set the config.Log.Level to error,defra.cli=info,... for example, which would fail validation. I have no moved the validation rules, as it will be validated anyways later in the call stack (in the ToLoggerConfig). Lastly, it fixes sourcenetwork#694, as an accidental oversight, potentially during a rebase/merge-conflict.
Relevant issue(s)
Resolves #693 #694
Description
There was a bug in the #658 that got merged which effectively broke the entire feature. Tests didn't catch it as they were accidentally poorly defined, as they would pass with the default logger settings as well as the custom ones set in the test.
There are two fixes in this PR that resolves the problem. During review, we decided to switch back the
Config.Log
fromConfig.Logger
, but the viperBind
calls were still usingBind(logger.loglevel)
(old name). Additionally, thevalidate
call on theconfig.Log
struct previously always returned nil (no errors), but was changed recently to validate the available options. But, if the--loglevel
option is provided it will set theconfig.Log.Level
toerror,defra.cli=info,...
for example, which would fail validation. I have no moved the validation rules, as it will be validated anyways later in the call stack (in theToLoggerConfig
).Lastly, it fixes #694, as an accidental oversight, potentially during a rebase/merge-conflict.
Tasks
How has this been tested?
Better defined integration tests that don't overlap with defaults.
Specify the platform(s) on which this was tested: