[eas-cli] create fingerprint on each update

[quinlanj]

Why

This PR computes a fingerprint for each update.

• If the update does not use the fingerprint policy, it calculates the fingerprint using the exported cli in the expo package for projects SDK 52+.
• If the update uses the fingerprint policy, it just uses the fingerprint that was previously calculated using expo-updates.

How

• Modified fingerprint computation to handle platform-specific cases
• Updated the fingerprint data structure to use fingerprintHash instead of the full fingerprint object
• Added support for computing fingerprints for projects without expo-updates
• Introduced new types and interfaces for handling fingerprint information groups
• Created utility functions for async map operations and fingerprint calculations
• Updated GraphQL schema to support new fingerprint-related fields

Test Plan

• on build: verify fingerprints till work
• on update: verify fingerprint is calculated for new project with SDK 52
• on update: verify no fingerprint is calculated for old project (< SDK 52)
• on update: verify fingerprint is reused for project with fingerprint runtime policy

[quinlanj]

• [eas-cli] pass on fingerprint info on republish #2708
• [eas-cli] create fingerprint on each update #2687 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

Size Change: +711 B (0%)

Total Size: 52.9 MB

Filename	Size	Change
./packages/eas-cli/dist/eas-linux-x64.tar.gz	52.9 MB	+711 B (0%)

_{compressed-size-action}

[codecov]

Codecov Report

Attention: Patch coverage is 50.00000% with 47 lines in your changes missing coverage. Please review.

Project coverage is 52.79%. Comparing base (fc3c1e7) to head (9eb89a7).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
packages/eas-cli/src/utils/fingerprintCli.ts	17.15%	29 Missing ⚠️
packages/eas-cli/src/project/publish.ts	82.86%	6 Missing ⚠️
packages/eas-cli/src/commands/update/index.ts	63.64%	3 Missing and 1 partial ⚠️
packages/eas-cli/src/utils/expodash/mapMapAsync.ts	55.56%	4 Missing ⚠️
packages/eas-cli/src/build/build.ts	0.00%	2 Missing ⚠️
.../eas-cli/src/project/resolveRuntimeVersionAsync.ts	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2687      +/-   ##
==========================================
+ Coverage   52.77%   52.79%   +0.03%     
==========================================
  Files         579      580       +1     
  Lines       22194    22260      +66     
  Branches     4343     4352       +9     
==========================================
+ Hits        11710    11750      +40     
- Misses      10448    10474      +26     
  Partials       36       36              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[github-actions]

Subscribed to pull request

File Patterns	Mentions
**/*	@szdziedzic, @khamilowicz, @sjchmiela
packages/eas-cli/src/build/**	@szdziedzic, @khamilowicz, @sjchmiela
packages/eas-cli/src/commands/update/**	@EvanBacon, @byCedric, @wschurman

Generated by CodeMention

[Kudo]

nit: the logic of this function is kind of complicated. would be good to split as smaller functions and add some unit test.
but fine if that requires too much effort.

[wschurman]

Think we also need to add this to republish. Probably just pull in the fingerprint from the previously-published update assuming we are sure it won't change between publish and republish (don't think we have another option since we can't re-calculate the fingerprint on republish since republish can't use any info from the current project state, code signing suffers from this fwiw)

[wschurman]

(if you want to do republish in a follow-up, request re-review on this one. this looks good otherwise)

[wschurman]

Also, should roll-back-to-embedded updates have this as well? (every command that calls publishUpdateGroupAsync should have it I think?)

[quinlanj]

@wschurman here is the PR for republishing (made separate because of extra dependencies on www changes): #2708

I dont think we need to pass on fingerprint info for rollback to embedded. A 'rollback to embedded' directive would always be compatible with whatever build that is targeted. Also, it would technically have the fingerprint of the receiving build (ideally all builds of the same runtime have the same fingerprint, but that's not necessarily the case)

[wschurman]

I dont think we need to pass on fingerprint info for rollback to embedded.

My guess is that it might be simpler product-wise to include them since they are just normal UpdateEntities (as are rollouts and republishes). Otherwise we'd need to special case the UI to explain why they don't have them for those updates?

A 'rollback to embedded' directive would always be compatible with whatever build that is targeted. Also, it would technically have the fingerprint of the receiving build (ideally all builds of the same runtime have the same fingerprint, but that's not necessarily the case)

I believe they're only compatible with builds with the same code signing key (and therefore theoretically runtime version as we advise people to change when they do a key change). I think since the code signing configuration is part of the fingerprint we should probably attach the fingerprint to directives.

[github-actions]

✅ Thank you for adding the changelog entry!