Archive Expo Snack Discord and Forums Newsletter

Continuous deployment

Edit this page

Learn how to use the fingerprint runtime version and GitHub actions for continuous deployment.

Prerequisites

You need to have a GitHub account and use it to host your git project.
You need to have an Expo token configured in your GitHub repository.

How to configure the EXPO_TOKEN environment variable on your GitHub repository

Navigate to expo.dev/settings/access-tokens and then:
Click Create token to create a new personal access token.
Copy the generated token.
Navigate to https://github.com/your-username/your-repo-name/settings/secrets/actions by replacing "your-username" and "your-repo-name" with your project's info.
Under Repository secrets, click New repository secret.
Create a secret with the name EXPO_TOKEN, and paste the copied access token in as the value.

GitHub Action: continuous-deploy-fingerprint

Available for SDK 52 and above.

Expo provides the continuous-deploy-fingerprint GitHub Action to continuously deploy React Native projects that use the fingerprint runtime version policy. It deploys every JS change as an EAS Update to all compatible builds over-the-air, and new builds are automatically created using EAS Build when a runtime change is detected.

How do I debug the commands that are run in the action?

Running your GitHub workflows in debug mode will automatically add the --debug flag to the commands run as part of the action, and the output will be available in the workflow run logs.

Fingerprint runtime versioning

The fingerprint runtime version policy uses the @expo/fingerprint package to generate a hash of your project when making a build or publishing an update, and then uses that hash as the runtime version. The hash is calculated based on dependencies, custom native code, native project files, and configuration, amongst other things.

By automatically calculating the runtime version, you don't have to be concerned about native layer compatibility with the JavaScript application when deploying updates to builds.

How does fingerprint generation differ between managed and bare workflows?

The default project files included in the fingerprint hash differs between managed and bare workflow projects. EAS automatically detects your workflow by checking if the android and ios and directories are gitignored. If they are, EAS will treat the project as a managed workflow project, thus dictating that a hash of the package.json dependencies are sufficient to determine fingerprint compatibility.

How do I debug fingerprint mismatches between my local machine and CI/CD?

If you notice different fingerprints being generated across different machines or environments, it may mean that unanticipated files are being included in the hash calculation. @expo/fingerprint has a predetermined set of files to include/exclude for hash calculation, but often your project setup may require additional excludes. For projects that include native directories (android and ios) this is more common.

We provide tools for identifying which files are causing fingerprint inconsistencies and mechanisms to exclude those files from fingerprint calculations for your project.

To identify differences in fingerprints on different machines or environments:

When running fingerprint generation commands on each machine/environment (npx expo-updates fingerprint:generate), pass --debug flag.
Diff outputs from those command runs to determine files causing the difference. These tools may be helpful:
- JSON Pretty Print to format the output.
- JSON Diff to compare the output and identify the files causing the discrepancies.

To exclude files causing the differences, add them to the .fingerprintignore file as described in the documentation for @expo/fingerprint.

App version numbers

When using continuous deployment, version number incrementation must be done automatically. While the specifics will differ based on the preferred numbering scheme, the general strategy is:

Before continuous deployment CI steps, check if a new release will be created (due to a new fingerprint).
If so, bump the version number in the source code and push the version bump commit.
Continue continuous deployment CI steps with the new commit.

An example is provided in the continuous-deploy-fingerprint GitHub Action documentation.

GitHub Action: expo-github-action

An alternative GitHub action is expo-github-action that can be used to publish updates on push and previews on pull requests. continuous-deploy-fingerprint uses fingerprints to determine if a build is needed or not to deploy an update, while expo-github-action will only publish updates.

To learn about publishing updates when code is pushed to the main branch, refer to the README.
To learn about Pull Request previews with expo-github-action, refer to the GitHub PR Previews guide.