-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
fastlane scan with --run_rosetta_simulator
selects the wrong simulator
#21293
Comments
@joshdholtz Is the destination selection working for you when For me it selects the first found simulator which is not what I expect. Direct invocation of |
Hi @nevil 👋 Mine logs the same thing as yours (the warning):
However, it correctly selects the device I chose (iPhone 14 Pro), Can you check what is the output Mine looks like this: xcodebuild -workspace redacted.xcworkspace -scheme redacted -derivedDataPath /Users/redacted/Library/Developer/Xcode/DerivedData/redacted-csqhgnllwxkxbjaimhoulguqkjvn -destination 'platform=iOS Simulator,id=C633B788-70BB-49D8-B454-24B501FCFD41,arch=x86_64' clean test | tee '/Users/redacted/Library/Logs/scan/redacted-redacted.log' | xcbeautify |
Thanks for taking time to check 🙇 The issue I'm seeing isn't really fastlane scan's fault as the same happens when invoking xcodebuild directly. This is my test case: import XCTest
@testable import RosettaTest
final class RosettaTestTests: XCTestCase {
func testIOSVersion() {
if #available(iOS 16, *) {
// The iPhone 12 simulator is iOS 15.5 so this should not fail
XCTFail("iOS 16")
}
}
} Output from $ xcodebuild -workspace RosettaTest.xcworkspace -scheme RosettaTest -showdestinations
2023-05-23 15:01:06.607 xcodebuild[37640:2297730] DVTCoreDeviceEnabledState: DVTCoreDeviceEnabledState_Disabled set via user default (DVTEnableCoreDevice=disabled)
Command line invocation:
/Applications/Xcode-14.3.1.app/Contents/Developer/usr/bin/xcodebuild -workspace RosettaTest.xcworkspace -scheme RosettaTest -showdestinations
User defaults from command line:
IDEPackageSupportUseBuiltinSCM = YES
Available destinations for the "RosettaTest" scheme:
{ platform:macOS, arch:arm64, variant:Designed for [iPad,iPhone], id:00006000-001871841AE2801E }
{ platform:iOS, id:dvtdevice-DVTiPhonePlaceholder-iphoneos:placeholder, name:Any iOS Device }
{ platform:iOS Simulator, id:dvtdevice-DVTiOSDeviceSimulatorPlaceholder-iphonesimulator:placeholder, name:Any iOS Simulator Device }
{ platform:iOS, id:d4fc2c1b042083c6e239e63f3ca140dba5d8910a, name:iPad Air2 SB }
{ platform:iOS, id:c70f4cbbce058a5a18aa65d3a1ec538fbc1385d4, name:iPhone 8 Dev }
{ platform:iOS Simulator, id:DA521529-88CC-4C71-960C-680FB6A23AAD, OS:16.4, name:iPhone 11 }
{ platform:iOS Simulator, id:F5E604EC-BDD1-4AF3-BC7A-46B62A758232, OS:15.5, name:iPhone 12 } Just specifying "iPhone 12" works as expected. bundle exec fastlane scan --clean --workspace RosettaTest.xcworkspace --scheme RosettaTest --configuration Debug --device "iPhone 12" Full output
Test result:
Trying Rosetta bundle exec fastlane scan --clean --workspace RosettaTest.xcworkspace --scheme RosettaTest --configuration Debug --device "iPhone 12" --run_rosetta_simulator Full output
The generated invocation is correct (id
|
Same happens to us. When can we expect a fix for that? |
I'm having the same issue, and as a result my tests fail due to the following issue: Signing for "ModuleTests" requires a development team. Select a development team in the Signing & Capabilities editor. It looks like the |
@nevil thanks for the detailed report 💪 @nevil @bartlomiejswierad-vodeno @fousa as far as I can tell, this looks like a bug on Xcode ( fastlane is generating the right Could you try passing the scan argument |
@rogerluan I'd like to point out the error made in the PR. Adding To resolve the issue, we can run TL;DR; Edit: |
@bartlomiejswierad-vodeno Actually using
|
Hey @bartlomiejswierad-vodeno, I appreciate the input, and although your rationale made sense to me, my tests work just fine 😬 ? Initially I thought you were right because I didn't experiment with set -o pipefail && env NSUnbufferedIO=YES xcodebuild -workspace redacted.xcworkspace -scheme redacted -derivedDataPath /Users/redacted/Library/Developer/Xcode/DerivedData/redacted-csqhgnllwxkxbjaimhoulguqkjvn -disableAutomaticPackageResolution -destination 'platform=iOS Simulator,id=C633B788-70BB-49D8-B454-24B501FCFD41,arch=x86_64' test And tests run just fine, under the expected simulator. Also, the logs confirm that the app is in fact not being compiled. |
@rogerluan https://github.com/nevil/RosettaTest It only has one unit test which I expect won't fail as I always specify to run on an iOS 15.5 simulator. func testIOSVersion() {
if #available(iOS 16, *) {
// The iPhone 12 simulator is iOS 15.5 so this should not fail
XCTFail("iOS 16")
}
} |
I have tested your sample code and I get the same issue you're seeing: the first simulator is used. In my case specifically, though, the first simulator happens to be an iPad on iOS 15.5, so the test pass, but it's by mere luck. Also, I isolated this issue outside of fastlane, to show it's related to xcodebuild: See last line of the log: Also, I tested my suggestion here about using e.g. |
Perhaps @bartlomiejswierad-vodeno can help us solve this? It seems like you have deeper knowledge around what's going on here 🙇 |
@rogerluan Well, I fixed it locally by setting Also, I just spent whole day on it yesterday, so I just tried everything to make it work because deadline for us to migrate CI build to M1 is close. @nevil If you sent the logs from the demo project you created, then it work for me. I even added some validation code to be 100% sure. This would not compile for other architecture. #if arch(x86_64) || !targetEnvironment(simulator)
#warning("This is good")
#else
#error("Not valid arch")
#endif Also I realized that picking destination by Command (I don't have iPhone 12 configured, so I used 13 on purpose):
|
Thanks for the insights. In our projects we will always run unit tests only in an x86 simulator (looking at you Google Chromecast SDK) so we can just change our project to use:
Not sure what to do for projects that need to support both arm and x86_64... Anyway, I think that |
Yes, fastlane does this, but if you observe in the 1st screenshot I posted here, the selection is done via ID (as fastlane does), and it still does not work as expected: see the last line of the screenshot, where it says the simulator that was used to run the tests was an iPad, even though the ID I passed to Notice how I completely removed fastlane out of the equation 🤔 neither of the screenshots I posted have anything to do with fastlane, it's just purely an issue on |
@rogerluan If you remove the So what i did (as @bartlomiejswierad-vodeno pointed out) was to to change the Architectures in the project to have (or xcodebuild by specifying only id : I noticed that 2.213.0 is now released... |
That's also a valid solution @nevil |
I'm not sure what to do with this issue. But if And yes, the root issue is that xcodebuild don't have a "flag" for doing what |
Getting the same issue, hope we can have a solution for this soon. |
Same issue with picking the wrong simulator even with the correct id. If it's not an issue with fastlane, do we have any issue opened for xcodebuild? |
@Kirikami xcodebuild is Xcode's CLI, thus owned by Apple, closed source. There's no public issue-tracking system for Xcode or xcodebuild, but anyone can open a radar with Apple directly |
@nevil not sure there's anything to be done, honestly. Perhaps it would make more sense, semantically, to name the fastlane flag something like "run_on_x86", because that is exactly what it does under the hood. And if when running under x86 xcodebuild doesn't work as expected, then that's an issue on xcodebuild and not fastlane (which is also what's happening). However, for the average joe, they'll be looking for "rosetta" in the API, docs, man, help menu, etc, and not "x86" 🤷♂️ so there's pros/cons to both options. |
I opened FB12195073 on May 20 but don't really expect to get any answers. Maybe someone will have some luck in a WWDC lab or something. |
For us, the simplest solution seems to be to add
|
I still couldn't reproduce the OP's issue locally, has anyone been able to? If so, could you perhaps provide steps to reproduce and maybe include a demo project? I think there may be different solutions to the problem but without a way of verifying them, it's hard for me to work on this 😬 |
Same problem here, xcargs: 'ARCHS=x86_64' and removing runRosettaSimulator helps, but still console outputs
which I found strange =/ also, idk if it relates, but reinstallApp argument do nothing:
in console, but it does nothing |
The arch keyword seems to only work with macOS simulators. It seems it was originally intended for
As discovered in this thread, adding
Same issue occurs when we allow |
New Issue Checklist
Issue Description
fastlane scan with
--run_rosetta_simulator
selects the wrong simulator when using--run_rosetta_simulator
.I'm using the changes from this PR #21284
gem "fastlane", :git => "https://github.com/fastlane/fastlane.git", :ref => "586b13f72ee21b5dcac26241435425614bde475c"
A special XCTestCase was added that fails with a text corresponding to the simulators iOS version.
When using
--run_rosetta_simulator
is specified, the selected simulator is the iPhone 11, iOS 16.4.Not the iPhone 12, iOS 15.5
Command executed
Complete output when running fastlane, including the stack trace and command used
Listed destinations
XCTest result:
As can be seen from the test result, the iPhone 11 simulator is selected even though iPhone 12 is specified.
Environment
The text was updated successfully, but these errors were encountered: