-
-
Notifications
You must be signed in to change notification settings - Fork 32.7k
gh-137973: Add a non-parallel test plan to the iOS testbed project #138018
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
Conversation
!buildbot iOS |
🤖 New build scheduled with the buildbot fleet by @freakboy3742 for commit 7d86d4e 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F138018%2Fmerge The command will test the builders whose names match following regular expression: The builders matched are:
|
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 did not do a detailed review of each change but, at a quick glance, I didn't see any obvious problems. With these changes, I found my standard make testios
setup to run without any issues (which wasn't always the case with iOS simulators) and the wall clock time from start to finish seemed to be significantly less. So looking good to me!
Thanks @freakboy3742 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
…ect (pythonGH-138018) Modifies the iOS testbed project to add a test plan. This simplifies the iOS test runner, as we can now use the built-in log streaming to see test results. It also allows for some other affordances, like providing a default LLDB config, and using a standardized mechanism for specifying test arguments. (cherry picked from commit 2ba2287) Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>
…ect (pythonGH-138018) Modifies the iOS testbed project to add a test plan. This simplifies the iOS test runner, as we can now use the built-in log streaming to see test results. It also allows for some other affordances, like providing a default LLDB config, and using a standardized mechanism for specifying test arguments. (cherry picked from commit 2ba2287) Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>
GH-138038 is a backport of this pull request to the 3.14 branch. |
GH-138039 is a backport of this pull request to the 3.13 branch. |
|
…ject (GH-138018) (#138039) Modifies the iOS testbed project to add a test plan. This simplifies the iOS test runner, as we can now use the built-in log streaming to see test results. It also allows for some other affordances, like providing a default LLDB config, and using a standardized mechanism for specifying test arguments. (cherry picked from commit 2ba2287) Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>
|
|
The buildbot failures are due to concurrency issues; I've modified the buildbot config to limit concurrent builds until I can develop a more permanent solution. |
Modifies the iOS testbed project to add a test plan.
Adding a test plan to the project has three main benefits:
Firstly, it provides the Xcode standard location for defining test arguments. This doesn't change anything for the documented use of the iOS testbed; but for anyone familiar with Xcode, it will be less surprising that using the app's
Info.plist
as a way to configure test arguments.Secondly, it allows defining an LLDB startup configuration, removing the need to manually disable signal breakpoints. This means the Xcode project will work out of the box, without the manual configuration of LLDB ignores that was previously required (and documented).
Lastly, and most importantly, it allows the default behavior of the test suite to be configured as non-parallel. The default behavior for iOS Xcode projects is to run in parallel, which means Xcode tries to launch 2 simulators; and because there will be 2 simulators, it's necessary for Xcode to clone the original simulator to provide independent copies.
The second simulator is never used for anything, because the CPython test suite is (at the Xcode level) a single XCTestCase. However, generating the clone and then launching 2 simulators obviously takes more time than just using the simulator that is ready.
However - more importantly, when running in parallel, Xcode doesn't stream test log output of the tests to the console (because parallel tests could cause stdout collisions). This required the iOS testbed to implement a moderately complex locking and simulator discovery mechanism to find the UUID of the test simulator, and then live stream the logs of that simulator so the user could view them.
So - by turning off parallelism, we can eliminate all that complexity, and just run the Xcode project as-is, and test output will appear in the standard Xcode output.
For added bonus points - the simulator locking and discovery logic is the cause of the issues with the recent 20250811
macos-15
image update on GitHub Actions - so by massively simplifying things, we can also restore service on GitHub Actions.For more added bonus points - if the system running the tests is under load, the separate log streaming approach can drop log messages. This doesn't happen if Xcode displays the test logs directly.
macos-15
runner. #137973📚 Documentation preview 📚: https://cpython-previews--138018.org.readthedocs.build/