Repository navigation
Conversation
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub. |
65f5c32 to
a935ff2
Compare
47b83a0 to
31a3a8f
Compare
cbde820 to
39ba534
Compare
c8f6be9 to
9386443
Compare
e6f04d9 to
c427f43
Compare
| timeout-minutes: 90 | ||
| android-e2e-build: | ||
| if: github.event.pull_request.draft == false | ||
| runs-on: blacksmith-8vcpu-ubuntu-2404 |
There was a problem hiding this comment.
Is this machine considered the best option for this type of jobs?
There was a problem hiding this comment.
Yes, tested different sizes and this one is most cost effective. However for running the tests we found that the blacksmith runners would crash / disconnect more often when running android emulators so we're using github hosted ones for now. Ideally we'd use these runners for everything, but can't currently.
| - name: Checkout repo | ||
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Setup Java environment |
There was a problem hiding this comment.
Guess the whole environment is set up by the chosen machine?
There was a problem hiding this comment.
The RNEF github actions does it internally if I remember correctly.
| DEBUG: false | ||
| SHARD_TOTAL: 4 | ||
| SHARD_INDEX: ${{ matrix.shard-index }} | ||
| ANDROID_EMULATOR_API_LEVEL: 31 |
There was a problem hiding this comment.
Don't we want the newest ones? e.g. API 35 pixel_9? Or is it not available?
There was a problem hiding this comment.
From our testing newer versions are less stable and randomly crash or disconnect a lot more.
|
|
||
| - name: Version debug | ||
| run: | | ||
| npx react-native info |
There was a problem hiding this comment.
Is it connected to this PR?
There was a problem hiding this comment.
Earlier versions removed the community CLI for RNEF CLI, but decided to keep both. Could revert this change.
There was a problem hiding this comment.
Haven't seen any problems in another project using RNEF but its up to you
Co-authored-by: Wojciech Lewicki <[email protected]>
|
@WoLewicki I think I addressed all your comments and fixed minor conflict in podfile.lock |
|
I'd approve it but CI is failing. |
|
Looks like something broke when RNEF needs to do a full rebuild, I tried bumping the version to see if it fixes it. Looks like this |
|
Not sure what happened, but it worked now. Should be good to go once tests pass! |
|
Hmm so I think we should trigger some clean build again, should e.g. bumping some native dependency be enough? |
|
Oh, ios timed out? |
I checked the build on android and it did a full build again, I saw the exact same code path that errored in the previous code execute with no problem :/ |
|
Bumped timeout on iOS, I think combinaison of using github hosted runners + the arm change might make builds a bit slower. It failed literally at the last second when it was uploading the ipa :( Added 15 min to be safe. |
|
@WoLewicki All passed! iOS build is still pending, but this doesn't affect that one. |
So do you think we should go forward and merge it then? If so, I'm up for it too and we can handle some problems in follow-ups. |
|
Yea I think it is fine, I’ll fix any issues we find in follow ups |
* Record e2e test failures * Cleanup
|
@jinchung Are we good to merge this? |
* Use RNEF CLI * Move tests to flow folder * Remove retry blocks * Fix * Update e2e/README.md Co-authored-by: Wojciech Lewicki <[email protected]> * fixes * Try bumping rnef * Increase timeout * Record e2e test failures (#6796) * Record e2e test failures * Cleanup * Set xcode version --------- Co-authored-by: Janic Duplessis <[email protected]> Co-authored-by: Wojciech Lewicki <[email protected]>
The `Ensure Simulator is fully booted` step in `ios-e2e.yml` polls `xcrun simctl list | grep "Booted"` with a 120-second timeout. The `simulator-action` that creates the simulator already supports a `wait_for_boot: true` input that uses Apple's `simctl bootstatus` internally, which is the supported mechanism for detecting simulator readiness. The custom loop was added in #6713 (Aug 2025) during the GH Actions migration with no documented rationale; presumably the action's native wait was simply overlooked at the time. We noticed the grep-based detection is fragile while working on the iOS 26 SDK migration. An iOS 26.4 simulator booted in ~36 seconds, yet our custom loop timed out at 120s because the `grep 'Booted'` pattern didn't match reliably during the boot transition. Swapping to the action's native wait fixed it cleanly in that context. This change backports the combined swap to develop's current iPhone 16 / iOS 18.5 setup. Behavior should be equivalent on green runs and more robust on slow boots. @janicduplessis pointed out on this PR that the built-in wait has historically been flaky: `simctl bootstatus` sometimes returns while the simulator isn't actually ready, or hangs outright. We actually observed that hang pattern on one shard here. To combat this the change also bumps the simulator-action from v4 to v5, which addresses this exact class of flake. v5 ships `boot_timeout_seconds: 360` and `boot_retries: 2` as defaults (see [#563](futureware-tech/simulator-action#563)), so a hung `bootstatus` call now bails after 6 minutes and retries up to twice before failing the step. No explicit config needed on our side. Ref FEPLAT-81.
Fixes APP-2922
What changed (plus any additional context for devs)
<test_index> % <total_shards> == <shard_index>. This allows also better control of logs structure and retries. Retries are now handled by the script and no longer need retry blocks in all tests.Screen recordings / screenshots
N/A
What to test
CI passes FAST