-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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: fix hang when running tests that need parsing with --interactive
#13980
base: master
Are you sure you want to change the base?
Conversation
I had a bit of a hard time trying to come up with a testcase for this, also because the test harness does not seem to be prepared to pass arbitrary options to |
4d27f58
to
217629d
Compare
The problem here is that TAP tests with
|
Would you like to try the approach in the comment above? |
217629d
to
eff716f
Compare
After a test run finishes we print a summary that sums up test counts by type, e.g. failed or skipped tests. In many cases though it is expected that most of the counts will be zero, and thus the summary is needlessly cluttered with irrelevant lines. This list of mostly-irrelevant results will grow in a subsequent commit where we introduce "Ignored" test results. Prepare for this by filtering results. Instead of unconditionally printing every result, we will now only print those results where we have at least one counted test. The exception is "Ok:" and "Fail:", which will always be printed. Suggested-by: Paolo Bonzini <[email protected]> Signed-off-by: Patrick Steinhardt <[email protected]>
Move the `console_mode` property into the TestRun Class. This will be required by a subsequent commit where we start to ignore test results for parsed interactive tests. Signed-off-by: Patrick Steinhardt <[email protected]>
When running tests in interactive mode then the standard file streams will remain connected to the executing terminal so that the user can interact with the tests. This has the consequence that Meson itself does not have access to those streams anymore, which is problematic for any of the test types that require parsing, like for example with the TAP protocol. This means that Meson is essentially flying blind in those cases because the test result cannot be determined by parsing the exit code of the test, but can only reliably be derived from the parsed output. One obvious solution to this problem would be to splice the test output so that both Meson and the user's terminal have access to it. But when running in interactive mode it is quite likely that the test itself will actually be driven from the command line, and the chance is high that the resulting data on stdout cannot be parsed as properly anymore. This is for example the case in the Git project, where interactive mode is typically used to drop the user into a shell or invoke a debugger. So continuing to treat the output as properly formatted output that can be parsed is likely a dead end in many use cases. Instead, we introduce a new "IGNORED" test result: when executing tests in interactive mode, and when the test type indicates that it requires parsing, we will not try to parse the test at all but mark the test result as ignored instead. Suggested-by: Paolo Bonzini <[email protected]> Signed-off-by: Patrick Steinhardt <[email protected]>
When running tests with `--interactive` we don't redirect stdin, stdout or stderr and instead pass them on to the user's console. This redirect causes us to hang in case the test in question needs parsing, like it is the case for TAP output, because we cannot read the process's stdout. Fix this hang by not parsing output when running in interactive mode. Signed-off-by: Patrick Steinhardt <[email protected]>
eff716f
to
748f18c
Compare
@bonzini Thanks for giving me a nudge. I wanted to get to it, but didn't yet find the time to do it. I've now got a version that seems to work alright. |
When running tests with
--interactive
we don't redirect stdin, stdout or stderr and instead pass them on to the user's console. This redirect causes us to hang in case the test in question needs parsing, like it is the case for TAP output, because we cannot read the process's stdout.Fix this hang by not parsing output when running in interactive mode.