Skip to content

Conversation

@freakboy3742
Copy link
Contributor

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-15 test 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_ARGS setting (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_ARGS is lightly processed. If there's a --managed or --connected value in CIBW_TEST_EXECUTION_ARGS, that value will be used by the testbed runner; if no such argument exists, --managed maxVersion will 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.

@freakboy3742 freakboy3742 requested a review from mhsmith as a code owner October 22, 2025 07:14
@freakboy3742 freakboy3742 requested review from joerick and mhsmith and removed request for mhsmith October 22, 2025 07:16
@freakboy3742 freakboy3742 requested a review from mhsmith October 23, 2025 02:38
Copy link
Contributor

@joerick joerick left a 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-

@freakboy3742
Copy link
Contributor Author

@joerick I've just pushed an update that includes:

  • Moving to test-execution = { args = [...] } as the syntax for configuration
  • Adding a default simulator on iOS when running under Github Actions on a macos-15 runner.
  • Links to the iOS and Android test runner documentation.

I've kept the explicit use of TEST_EXECUTION in the GitHub Actions CI configuration, as it's a viable "live test" of the new functionality.

Copy link
Contributor

@joerick joerick left a 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...

Comment on lines 674 to 678
test_execution_args = [
"--simulator",
"iPhone 16e,OS=18.5",
*test_execution_args,
]
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants