-
Notifications
You must be signed in to change notification settings - Fork 293
Add configuration option for test executor arguments #2636
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
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Malcolm Smith <[email protected]>
…the default args to the test runner.
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.
Thank you for your work on this! It looks good. A few comments-
|
@joerick I've just pushed an update that includes:
I've kept the explicit use of |
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 for these latest changes - just a couple things...
cibuildwheel/platforms/ios.py
Outdated
| test_execution_args = [ | ||
| "--simulator", | ||
| "iPhone 16e,OS=18.5", | ||
| *test_execution_args, | ||
| ] |
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.
It would be nice if the user could pass test-execution = "args: --simulator auto" to activate the select_simulator_device(platform) function from the test script. But I suppose that's a CPython change. Not essential, this is okay, it's probably a temporary issues anyway.
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.
Yes - adding auto would require an upstream CPython change; and "auto" is already the default behavior for the iOS test runner.
This is only needed as a workaround for the current set of GitHub Actions weirdness - and the 2 month release cadence of CPython definitely doesn't lend itself to hard-coding defaults like this.
Co-authored-by: Joe Rickerby <[email protected]>
iOS and Android test suites are executed using a testbed app. This app needs to be started, and the test arguments (the value of
test_command) is passed to that testbed.However, the testbed app itself has configuration arguments, and it can sometimes be useful to be able to use these arguments.
This issue has become mildly critical as a result of the recent changes to the
macos-15test runner. At present, the simulator that is picked by default by the iOS test runner is entirely valid from the perspective of Xcode, but then refuses to launch.This is a known issue with the macOS-15 runner that GitHub is investigating; but it's not a once-off issue. When Xcode 16.4 was released, it removed the "iPhone SE" simulator as a default image, and as there was no way to configure the simulator used at runtime, a full update of the iOS support packages and a cibuildwheel release was necessary to resolve the issue.
So - this PR adds a
CIBW_TEST_EXECUTION_ARGSsetting (with related platform-specific alternatives). These arguments are passed to the testbed runner on iOS and Android.As Android requires explicitly specifying the simulator to use as part of the runner arguments, the value of
CIBW_TEST_EXECUTION_ARGSis lightly processed. If there's a--managedor--connectedvalue inCIBW_TEST_EXECUTION_ARGS, that value will be used by the testbed runner; if no such argument exists,--managed maxVersionwill be used by the test runner.I'm not entirely sure how best to test this; it's in a portion of the code that can't be easily tested without actually starting simulators, and... well... the problem that led to this PR is that we can't use other simulators :-) So - I've gone with testing this empirically through the Github Actions configuration, passing in the necessary arguments so that on GitHub, simulators are specified on iOS and Android x86 simulator. On other platforms, the default behavior will continue to operate.