search

expo / expo-github-action

Expo GitHub Action makes it easy to automate EAS builds or updates
MIT License
795 stars 77 forks source link

feature: add fingerprint integration #231

Closed Kudo closed 1 year ago

Kudo commented 1 year ago

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:

preview-build

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

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:

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

Kudo commented 1 year ago

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 commented 1 year ago

further added a feature to show a link to latest compatible eas build Screenshot 2023-09-19 at 2 02 00 AM

expo-bot commented 11 months ago

:tada: This PR is included in version 8.1.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket: