-
Notifications
You must be signed in to change notification settings - Fork 33
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
Test updates (Enable race detection and disable output interceptor) #956
Conversation
This creates a lot of extra output during the test runs which is really distracting, and makes the output virtually useless. Apart from that is can cause the entiore test run to freeze under certain situtations (which has happened a few times lately) due to the issue described here. https://github.com/onsi/ginkgo/blob/104752fa2e97f04b1300754e710c419a63d2d30c/internal/output_interceptor.go#L13 Signed-off-by: Michael Nairn <[email protected]>
Tests are likely going to fail because of a a race in the authorino tests:
Probably the reason we are getting random failures on those tests |
@@ -127,7 +127,6 @@ func TestMain(m *testing.M) { | |||
logger := log.NewLogger( | |||
log.SetLevel(log.DebugLevel), | |||
log.SetMode(log.ModeDev), | |||
log.WriteTo(GinkgoWriter), |
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.
Confused here. Writting to GinkgoWriter should be helpful as it only shows errors when the test fails and not when the test passes. That is desirable, isn't it??
Or maybe you want to have logs disabled entirely and only activate logs when I run one test?
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 think this is an issue with ginkgo personally, or maybe i just don't know how to use it.
You are correct, anything written to GinkgoWriter shouldn't appear unless it fails, that is unless you use the -v
option on ginkgo and then it will spit everything out regardless.
Problem is the output without -v
is rubbish as it doesn't even tell you what tests it's running, just dots. What i would like is the output you get with -v
, without the logs unless you get an error but i can't figure out any magic combination to make that happen.
This is the lowest priority thing in this PR btw, I'd happily drop that for now. The other changes are more important.
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.
What i would like is the output you get with -v, without the logs unless you get an error
+1
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.
Problem is the output without -v is rubbish as it doesn't even tell you what tests it's running
I do not see it as a problem. What is the problem there? We can make it optional, something that you can enable/disable.
Anyway. I am not blocking this in any way. Feel free to remove the configuration to write to GinkgoWriter.
LGTM
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.
Being able to optionally log.WriteTo(GinkgoWriter)
(default to false
) would be nice, I guess. The otherwise noisy output sometimes helps us spot silent issues in advance, even when the tests succeed.
What about adding an env var to control it? (Willing to give up completely on the idea if you say it's too ugly of a solution.) We'd have to add it to the workflow_dispatch
as a parameter too.
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.
Yeah, this outputting happened since moving to the policy-machinery (previous to this, it worked as it should by outputting logs only when a test fails).
So this looks good to me until we resolve why the policy machinery is causing 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.
I have removed disabling the logs entirely from this PR, Will look at it separately, as i said it was the least important thing here.
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.
76d33f7
to
9062703
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.
Looks good to me 👍
This will cause the test suite to fail if any race condition is detected during the execution of the tests. Note: When the tests are run in parallel this does not output a descriptive message for the failure. If it fails for seemingly random reasons you should try running the test suite without parallel processes enabled. Signed-off-by: Michael Nairn <[email protected]>
Enables the race detector on locally running instances https://go.dev/doc/articles/race_detector. This will report useful information in the logs about race related issues. Signed-off-by: Michael Nairn <[email protected]>
Signed-off-by: Michael Nairn <[email protected]>
9062703
to
521bd87
Compare
tests: Disable all output capture in ginkgo tests
This creates a lot of extra output during the test runs which is really distracting, and makes the output virtually useless.
Apart from that it can cause the entire test run to freeze under certain situations (which has happened a few times lately) due to the issue described here.
https://github.com/onsi/ginkgo/blob/104752fa2e97f04b1300754e710c419a63d2d30c/internal/output_interceptor.go#L13
tests: Add --race option to ginkgo run
This will cause the test suite to fail if any race condition is detected during the execution of the tests.
Note: When the tests are run in parallel this does not output a descriptive message for the failure. If it fails for seemingly random reasons you should try running the test suite without parallel processes enabled.
dev: Add --race option to make run task
Enables the race detector on locally running instances https://go.dev/doc/articles/race_detector. This will report useful
information in the logs about race related issues.
Example output https://gist.github.com/mikenairn/a165c9e8076f3c3437a066e8af5a9ce5