-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Do not force STDIO output for Linux example apps #34232
Conversation
PR #34232: Size comparison from 6e31453 to f1c716b Full report (85 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
PR #34232: Size comparison from 9306418 to c8c4486 Full report (85 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
PR #34232: Size comparison from 9306418 to 145a4ea Full report (85 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
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.
Test failures are:
raise Exception('Timeout while waiting for %s' % waitForString)
because the tests are waiting for some stdio output from the example apps that never comes.
I expect this is actually quite common in workflows involving the example apps (e.g. it's very common for people to find the relevant pairing code in the stdio output). And certainly we have a bunch of tests that log things from those apps to files in CI and expect those logs to be available later if the test fails.
So I think we need to:
- Decide whether we actually want to change the default behavior, given the significant pain this will impose on people who currently use the example apps.
- Decide whether this should be an across-the-board change or whether some commonly-used example apps where this could be a particular problem should default to stdio (for now, or in general).
- Fix all our build documentation to describe the options for logging and how to select the one you want (no matter what the default is).
- If we change the default behavior for some apps, ensure that all existing testing that uses those apps is audited to see whether it's OK with the behavior change, and if not update the relevant build args.
But long story short: as-is this will break a ton of people's workflows. A bunch of in-tree ones (some of them leading to CI failures), but also lots of out-of-tree ones.
Yes, I'm aware of that. Now, I'm trying to figure how much work would it be to add support for changing logging to stdio for CI (and potentially other out of tree cases) while still allowing to build example apps with proper platform logging. The case is, that I would like to use the example app on a real device without mich hassle. For Linux apps it's not an issue since the platform logging happens to be stdout as well. But, Darwin and Tizen (Tizen is my real case) by default use dedicated logger. However, the example apps are both based on Linux example platform code, so that's why I'd like the platform common code not to force stdio logging. I'll convert this PR to draft for now. |
Problem
Example apps should be designed as real applications. Hence, they should integrate with platform logger instead of logging to stdio.
Changes
Testing
CI will verify potential build breaks.