-
Notifications
You must be signed in to change notification settings - Fork 37
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
Xcode 14.3 run in rosetta simulator. Arch in destination gets ignored. #226
Comments
Hi @KunzManuel , I couldn't reproduce the issue with my sample projects. Do you have an example project, which I could use for reproducing the issue and to verify the suggested approach? Is the module mentioned in the error a swift package dependency? I came across this writing: Some pits of using SPM and Build Configuration in Xcode, which suggests updating build settings for resolving a similar problem. |
Hello, unfortunately I can not share the project. |
@KunzManuel have you tried Apple's Resolving architecture build errors on Apple silicon guide? |
@godrei Yes unfortunately non of it worked for me. |
Hi! I have the exact same issue. My project already have the arm64 as excluded arch as explained by Apple in Resolving architecture build errors on Apple silicon guide. However this means we need to run Rosetta Simulators for Xcode 14.3, which normally should be done by adding the |
I'm also dealing with this issue and my Bitrise project has now been marked "abandoned" because I cannot get it to build on CI. I skimmed over the code, and it looks like what this step does is use the destination identifier to retrieve the UUID of the simulator. That works but discards the arch info which is how Apple expects you to target Rosetta simulator destinations from the command line. That said, I think the arch parameter may not work before Xcode 14.3 or 14.2. |
Suggestion released in https://github.com/bitrise-steplib/steps-xcode-test/releases/tag/4.7.3. |
4.7.3 solved my problem. Thanks |
@robinkunde @StrAbZ @KunzManuel In addition of passing the arch flag through found a better way to override Xcode Simulator selector buginess using the start-xcode-simulator Step: - xcode-start-simulator:
inputs:
- destination: platform=iOS Simulator,name=Bitrise iOS default,OS=latest,arch=x86_64 #Additional arch flag added here
- xcode-test:
inputs:
- destination: $BITRISE_XCODE_DESTINATION # Use the same destination as the xcode-start-simulator Step
- project_path: ./ios-sample/ios-sample.xcodeproj
- scheme: ios-sample
# Disabling parallel testing ensures that prebooted device is used. ARCHS=x86_64 is optional, to enable project compilation
- xcodebuild_options: -verbose -parallel-testing-enabled NO ARCHS=x86_64
- collect_simulator_diagnostics: never # This is the default |
We are still having issues even after 4.7.4 update and @lpusok suggested changes (to start simulator before test step). Locally and on local Bitrise CLI build everything works as expected, but when running through Bitrise (non-local) we are experiencing this error:
|
@sleivysarnas What happens if you set the destination directly in the xcode-test Step ( |
@lpusok exactly the same error |
Hello, we had the same issue and this fixed it for us. We also updated to the latest version at this point (5.0.1) thank you! |
@lpusok, I'm getting the same error no matter how I'm launching the x86_64 simulator. Doesn't matter if I use Start Simulator step, or put I've logged into Bitrise with remote access (no build step, just with steps containing project setup and a script with Firstly, I tried opening up Xcode, selecting any Rosetta-enabled iOS simulator and then tried running the tests (from Xcode's interface). The Rosetta simulator launched successfully and the tests succeeded successfully. I then tried to retest everything with CLI. I tried using command:
but the test failed due to In another attempt, I checked which simulators were running using I extracted its
The build still failed in a similar manner, however, when analysing the logs, I've encountered that immediately after the start of the process,
How can it be that there are now multiple instances of the same simulator? Could it be that one of them is Rosetta enabled and the other one is standard? I assume that the first destination is the standard one, because if it was Rosetta simulator, the tests would have succeeded? For the record, we are using "Xcode 14.3.x, on macOS 13.2 (Ventura)" stack and "Xcode Test for iOS" of version 5.0.1 (although it should not matter because I was logged in directly to Bitrise and ran the commands myself). Please help us, because we haven't been able to run any tests after Bitrise switched to M1 😕 |
I am having the same issue with unit tests failing after move to M1. This is due to the workflow is using a pre-warmed device, which means it's not using the specified simulator we defined.
I reached out to their support team, and they suggested to raise our project's minimum deployment target instead, which is not acceptable! We are the customers and they should cater us not the other way around. I am so disappointed with the response they provided. |
For the record, when we updated to "Xcode 15.0.x" stack, the issue was resolved. |
you're right @kkizlaitis I am able to get successful test execution using Xcode 15.2 stack. |
The issue reappeared on Stack Xcode 16.1.x 😞 This worked previously:
But now, it's throwing this error:
|
Troubleshooting
Useful information
Issue description
On migrating a project to the M1 setup our team ran into a problem with building our tests with the Xcode Test for iOS step.
Running with Xcode 14.3 and the M1 large we got the error:
could not find module 'Example' for target 'x86_64-apple-ios-simulator'; found: arm64-apple-ios-simulator
This problem seems to come with Xcode 14.3 which no longer runs in rosetta mode. Release notes
But Xcode 14.3 still allows to run a simulator in rosetta mode. To enable this the destination has to be extended by the
arch
param.-destination "platform=iOS Simulator,name=iPhone 14,arch=x86_64"
By having a quick look into the code you can see that this arch param is currently ignored. The destination is parsed and the identifier of the simulator is appended to the xcodebuild command.
The text was updated successfully, but these errors were encountered: