-
Notifications
You must be signed in to change notification settings - Fork 41
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
Update to k6-core master and fix logCache logger #842
Conversation
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, just wondering whether it's worth logging something when anything unexpected happens.
tests/logrus_hook.go
Outdated
if ll, ok := fl.(*logrus.Logger); ok { | ||
logger = ll | ||
} else { | ||
logger = logrus.New() |
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.
Would it be a good idea to log a warning as we do in #824 when fl
is not the expected type?
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.
I thought that this was unnecessary considering that this is only used in integration tests, and we'll probably ignore it anyway and just focus on the test results. But if you still think it can be useful for some cases let me know and we can add it 👍
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.
Tbh, I don't fully understand how it's used, so it's why i'm leaning towards making things clearer with a log message. But, if you know what's going on then i'm happy to leave it as is.
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.
Actually, reviewing this to better explain the context, I think the implementation is not exactly correct, as using the default logger here (in case the provided by state.Logger
is not of type *logrus.Logger
), will make the tests fail because that "default logger" is in the end not used by our implementation, so no hooks will be executed. This case is different from the one implemented in #824 where we actually replace one logger for another.
I think we should explicitly return an error if the given logger is not of type *logrus.Logger
and fail the test, until we fix #818.
Let me make the changes for this 👍
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.
Brilliant, i like it 🙂
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.
Pushed a new version in d506083.
Now, the tests will fail also if the given logger is not of type *logrus.Logger
, but in this case the behavior is less misleading.
Currently the tests don't fail because we ensure that the "initial" state.Logger
is a *logrus.Logger
when our implementation of log.New
is called, or either create a new default one, as modified in #824 .
1100548
to
d506083
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 👍 With one suggestion.
Replace the current panic usage when building our test browser implementation and use testing pkg Fatal/Fatalf methods instead. This avoids having to deal with panic stack trace during tests execution.
d506083
to
8740dd4
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.
Thanks, some suggestions.
This commit fixes an incompatibility detected with k6 core usage of state.Logger, which has been modified in grafana/k6#2960. Co-authored-by: İnanç Gümüş <inanc.gumus@grafana.com>
8740dd4
to
1c23598
Compare
This PR fixes an incompatibility detected with k6 core usage of
state.Logger
, which has been modified in grafana/k6#2960.This is done following the same approach as in #824 meanwhile a bigger refactor is applied, as defined in #818.
Closes #841 .