Fix run-ios not turning on Simulator app
#18721
Conversation
facebook-github-bot
added
the
CLA Signed
react-native-bot
added
Missing Test Plan
facebook-github-bot
added
the
Import Started
There was a problem hiding this comment.
@hramos is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
facebook-github-bot
added
Import Failed
and removed
Import Started
|
I tried to merge this pull request into the Facebook internal repo but some checks failed. To unblock yourself please check the following: Does this pull request pass all open source tests on GitHub? If not please fix those. Does the code still apply cleanly on top of GitHub master? If not can please rebase. In all other cases this means some internal test failed, for example a part of a fb app won't work with this pull request. I've added the Import Failed label to this pull request so it is easy for someone at fb to find the pull request and check what failed. If you don't see anyone comment in a few days feel free to comment mentioning one of the core contributors to the project so they get a notification. |
|
I believe I tested it with simulator not running as well, but apparently there was an oversight. Anyway, nice there's a solution already. |
| * it will not boot the "default" device, but the one we set. If the app is already running, | ||
| * this flag has no effect. | ||
| */ | ||
| child_process.execFileSync('open', [ |
There was a problem hiding this comment.
I believe open -a Simulator should launch the simulator as well, without specifying a full path. Although not sure if you're then able to pass it additional flags
There was a problem hiding this comment.
After further investigation, I think you should be able to use;
open -a Simulator --args -CurrentDeviceUDID ...
|
@angly-cat @koenpunt I am wondering whether we should stick to what we already have in master or keep using this approach. Any ideas? This one uses sort of dedicated and less hacky API for launching the simulator (unfortunately, in headless mode so hack for Simulator app is still needed). |
|
I think if we use the |
|
Not really - the `open -a Simulator --args -CurrentDeviceUDID` will only
launch the given simulator first time. That means if Simulator app is
already running, `open` will be a noop action and it will just make the
Simulator app focus. That's why we need `xcrun simctl` to do the real work.
Since both commands seem to handle all states w/o issues, there are no if
statements around.
…On Mon, 9 Apr 2018 at 20:55 Koen Punt ***@***.***> wrote:
I think if we use the open -a Simulator --args -CurrentDeviceUDID ...
approach, the xcrun simctl boot ... is no longer necessary, since the
simulator will be booted already, right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#18721 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACWcxk3zs_5kRJFJn_Y3V4bCc5meC4GAks5tm66ugaJpZM4TJ4H7>
.
|
|
Ah, I see, yeah that's true. |
|
Should I try to land this again? |
|
CLI has been moved. |
Right now,
run-ioswill "boot" Simulator in the headless mode in the background, as long as the Simulator.app is not running. It is exactly what "detox" does - it executes your test suite in the background.It seems to me that the author of this change was testing it with
Simulator.appopen.In order to fix this behavior, we have to make sure it runs before we attempt booting.
This passed through the release process since we don't use
run-iosthere (it recommends turning on XCode and testing manually which is what I have done recently too).CC: @kelset @koenpunt @hramos
Related: #18681