Skip to content

E2E CI V2 - #6713

Merged
jinchung merged 11 commits into
developfrom
eq/rnef-2
Aug 18, 2025
Merged

jinchung merged 11 commits into
developfrom
eq/rnef-2

Conversation

@EQuimper

@EQuimper EQuimper commented Jun 26, 2025 •

Copy link
Copy Markdown
Contributor

Fixes APP-2922

What changed (plus any additional context for devs)

  • Speed up build by reusing artifacts with RNEF github action. Native build are now reused if the dependencies did not change. Then the JS is re-bundled and replaced in the previously compiled binary.
  • Rewrite the e2e test runner to support sharding across jobs. The idea here is to have one job build the app, then multiple jobs each pull the app and run a subset of tests. The maestro test runner (running maestro command on a folder) doesn't support this so I wrote a script that will discover the tests and run maestro individually on each test file. This runner supports sharding by passing a shard number and the total number of shards. It will then only run tests at <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.
  • Move iOS tests to github hosted runners to leverage concurrency. We only have 3 hosted runners so this allows having proper sharding on iOS too. Need to discuss costs first before moving forward with that one.

Screen recordings / screenshots

N/A

What to test

CI passes FAST

@jinchung

jinchung commented Jul 7, 2025

Copy link
Copy Markdown
Member

Launch in simulator or device for cba0b4f

@jinchung

jinchung commented Jul 8, 2025

Copy link
Copy Markdown
Member

Launch in simulator or device for 5b369eb

@jinchung

jinchung commented Jul 8, 2025

Copy link
Copy Markdown
Member

Launch in simulator or device for b070c7f

@janicduplessis
janicduplessis force-pushed the @janic/upgrade-rn branch 4 times, most recently from 47b83a0 to 31a3a8f Compare July 18, 2025 14:22
@jinchung

Copy link
Copy Markdown
Member

Launch in simulator or device for cec8af1

@jinchung

jinchung commented Aug 1, 2025

Copy link
Copy Markdown
Member

Launch in simulator or device for 24229be

Base automatically changed from @janic/upgrade-rn to develop August 5, 2025 01:25
@janicduplessis
janicduplessis force-pushed the eq/rnef-2 branch 4 times, most recently from c8f6be9 to 9386443 Compare August 5, 2025 03:00
@jinchung

jinchung commented Aug 5, 2025

Copy link
Copy Markdown
Member

Launch in simulator or device for ed992c5

@jinchung

jinchung commented Aug 8, 2025

Copy link
Copy Markdown
Member

Launch in simulator or device for 6d73f17

@rainbow-me rainbow-me deleted a comment from github-actions Bot Aug 8, 2025

@WoLewicki WoLewicki left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some comments

Comment thread .github/workflows/android-e2e.yml Resolved
timeout-minutes: 90
android-e2e-build:
if: github.event.pull_request.draft == false
runs-on: blacksmith-8vcpu-ubuntu-2404

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this machine considered the best option for this type of jobs?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guess the whole environment is set up by the chosen machine?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The RNEF github actions does it internally if I remember correctly.

Comment thread .github/workflows/android-e2e.yml Resolved
DEBUG: false
SHARD_TOTAL: 4
SHARD_INDEX: ${{ matrix.shard-index }}
ANDROID_EMULATOR_API_LEVEL: 31

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we want the newest ones? e.g. API 35 pixel_9? Or is it not available?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From our testing newer versions are less stable and randomly crash or disconnect a lot more.

Comment thread .github/workflows/ios-e2e.yml Resolved

- name: Version debug
run: |
npx react-native info

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it connected to this PR?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Earlier versions removed the community CLI for RNEF CLI, but decided to keep both. Could revert this change.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't seen any problems in another project using RNEF but its up to you

Comment thread e2e/README.md Resolved
Comment thread ios/Podfile Resolved
@janicduplessis

Copy link
Copy Markdown
Contributor

@WoLewicki I think I addressed all your comments and fixed minor conflict in podfile.lock

@jinchung

Copy link
Copy Markdown
Member

Launch in simulator or device for c139783

@WoLewicki

Copy link
Copy Markdown
Contributor

I'd approve it but CI is failing.

@janicduplessis

Copy link
Copy Markdown
Contributor

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 Run OUTPUT=$(npx rnef remote-cache list --name rnef-***-release-9a6f61ff7d935c23bbf89e7e73358ec4b9f39604 --json) returns non-zero exit code now which makes the action fail.

@janicduplessis

Copy link
Copy Markdown
Contributor

Not sure what happened, but it worked now. Should be good to go once tests pass!

@WoLewicki

Copy link
Copy Markdown
Contributor

Hmm so I think we should trigger some clean build again, should e.g. bumping some native dependency be enough?

@WoLewicki

Copy link
Copy Markdown
Contributor

Oh, ios timed out?

@janicduplessis

Copy link
Copy Markdown
Contributor

Hmm so I think we should trigger some clean build again, should e.g. bumping some native dependency be enough?

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 :/

@janicduplessis

janicduplessis commented Aug 13, 2025 •

Copy link
Copy Markdown
Contributor

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.

@janicduplessis

Copy link
Copy Markdown
Contributor

@WoLewicki All passed! iOS build is still pending, but this doesn't affect that one.

@WoLewicki

Copy link
Copy Markdown
Contributor

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 :/

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.

@janicduplessis

Copy link
Copy Markdown
Contributor

Yea I think it is fine, I’ll fix any issues we find in follow ups

@jinchung

Copy link
Copy Markdown
Member

Launch in simulator or device for 91900f5

* Record e2e test failures

* Cleanup
@jinchung

Copy link
Copy Markdown
Member

Launch in simulator or device for 42e6c00

@jinchung

Copy link
Copy Markdown
Member

Launch in simulator or device for e2eb60f

@janicduplessis

Copy link
Copy Markdown
Contributor

@jinchung Are we good to merge this?

@jinchung
jinchung merged commit 65e1902 into develop Aug 18, 2025
@jinchung
jinchung deleted the eq/rnef-2 branch August 18, 2025 22:28
ibrahimtaveras00 pushed a commit that referenced this pull request Aug 25, 2025
* 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]>
olerass added a commit that referenced this pull request Apr 22, 2026
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.
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