feature: add fingerprint integration

[Kudo]

Why

to dogfood @expo/fingerprint, this pr tries to the fingerprint integration.
close ENG-8599

for updating doc, i will do it in a separated pr.

How

this pr introduces two new actions, mainly designed for pull requests.

fingerprint

the action will check the fingerprint from the pr head commit against base commit and just output the fingerprint diff. this could be used for something like pr labeler:

• fingerprint not changed
  

• fingerprint changed
  

preview-build

the action will check the fingerprint from the pr head commit against base commit and create eas builds if necessary. example workflow

• fingerprint not changed
  

• fingerprint not changed and found compatible EAS Build
  

• fingerprint changed
  

Implementations

check the high-level design first: https://www.notion.so/expo/expo-github-action-preview-build-92a444c9e4b84726a85b0bf4ef619f6c
to check whether the pr has fingerprint changes, we keep track gitCommitSha <-> fingerprint <-> easBuildId in a sqlite database and keep it in the github actions cache. the remaining part are just github integration like commenting or eas build command executions.

some challenges i had in this pr:

ncc

i want to import the @expo/fingerprint from the version user specified in yaml, not the version prebundled when we use ncc to build. this is more like a dynamic require for ncc. other than that, sqlite3 has some prebuilt native node-pre-gyp
binaries. if i trigger ncc build on macos, the darwin binary cannot run on github linux or windows runners. to do this, mainly have two points here:

• making external require from ncc
• we don't want to install sqlite3 or @expo/fingerprint into user's project root. rather than that we install to github tool directory. we should further mutate process.env['NODE_PATH'] to let nodejs further search the github tool directory when using require('sqlite3').

github actions cache mutation

github actions cache is designed to be immutable. as long as the cache is changed, you should have a new cache key. i don't want to pollute user's cache and have many fingerprint-db-v1, fingerprint-db-v2, fingerprint-db-v3 and so on. i just have to use the github api to remove the cache key before saving new database. the downside is that we need actions: write permission when integrating the action.

github actions cache matching scope

from the design of github actions cache, when saving cache in a branch, they will actually save the cache key in its branch's namespace. when updating database in a pr branch, saving the fingerprint-db cache will not update the fingerprint-db cache on main branch. as the result, we have to add on.push.branches: [main] from the workflow and update fingerprint database when prs merged back and push to main branch. that make the main branch's database updated when new prs coming.

to further update easBuildId from pr branches in the database, when a pr merged back to main branch. we should use github api to find the associated pr from the merge commit, find the pr comment we added, and find the easBuildId in the hidden metadata in the comment.

Risks

what if concurrent github actions workflows pushed back to main branch, the database may be overwritten in unexpected state. in this case, currently i have to use the github actions concurrency to limit the concurrency group when pushing on main:

concurrency: fingerprint-${{ github.event_name != 'pull_request' && 'main' || github.run_id }}

Test Plan

• adding some unit tests for db related code
• otherwise test the github integration on the example app: https://github.com/Kudo/eas-app
  • workflows
  • pr that has fingerprint changes
  • pr that is fingerprint compatible

[byCedric]

It looks good so far, but have some reservations about using SQLite through github caches 😄 We'll see how that goes in testing.

Can you add two readmes next to the action.yml that describes these actions? E.g. copy https://github.com/expo/expo-github-action/blob/main/preview/README.md and add a warning, like this, that mentions it's still experimental?

[Kudo]

Can you add two readmes next to the action.yml that describes these actions? E.g. copy https://github.com/expo/expo-github-action/blob/main/preview/README.md and add a warning, like this, that mentions it's still experimental?

sure thing! plan to add READMEs in a separated pr. will open the pr later.

[Kudo]

further added a feature to show a link to latest compatible eas build

[expo-bot]

🎉 This PR is included in version 8.1.0 🎉

The release is available on:

• 8.1.0
• GitHub release

Your semantic-release bot 📦🚀