[expo-updates][e2e] Add e2e for fingerprint policy

[wschurman]

Why

This adds an e2e test for the fingerprint runtime version policy in a generic project (the e2e project). The runtime version is calculated during the build and during the manifest serving.

Closes ENG-12110.

How

Add test and workflow.

Test Plan

Run generation and test locally, see it works.
Wait for CI to ensure it works in CI.

Checklist

• Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md).
• Conforms with the Documentation Writing Style Guide
• This diff will work correctly for npx expo prebuild & EAS Build (eg: updated a module plugin).

[linear]

ENG-12110 Add e2e test for fingerprint

[expo-bot]

Hi there! 👋 I'm a bot whose goal is to ensure your contributions meet our guidelines.

I've found some issues in your pull request that should be addressed (click on them for more details) 👇

⚠️ Suggestion: Missing changelog entries

Your changes should be noted in the changelog. Read Updating Changelogs guide and consider adding an appropriate entry to the following changelogs:

• packages/expo-updates/CHANGELOG.md

---

Generated by ExpoBot 🤖 against 7aa5eda

[Kudo]

it seems the new fingerprint e2e on ios is failed.

btw i would recommend that if we could find a way to aggregate these updates e2e tests.

• ideally, if we could aggregate some of these tests into a detox dedicated test-suite file, then we could save native rebuild time quite a lot.
• if that's not feasible, for example changing runtimeVersion requires native build. could we use eas custom build to incrementally build only for the runtimeVersion?
• if all of the above are not feasible, at least use github action matrix to merge some of the yml. this is an example from test-suite ci

[wschurman]

it seems the new fingerprint e2e on ios is failed.

Ugh, looking.

• ideally, if we could aggregate some of these tests into a detox dedicated test-suite file, then we could save native rebuild time quite a lot.
• if that's not feasible, for example changing runtimeVersion requires native build. could we use eas custom build to incrementally build only for the runtimeVersion?

Unfortunately all these flavors require distinct native builds due to the nature of the system (config is hardcoded in binary).

could we use eas custom build to incrementally build only for the runtimeVersion?

Not sure I follow. Mind elaborating? I'm all for speeding this up.

[Kudo]

don't want to block this work. we could merge is as long as current fingerprint e2e is passed. we could work on incremental eas build in the future. (i could also try for the custom builds a little bit)