eas build configuration

23 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Configure eas.json to build APKs

To generate an .apk, modify eas.json by adding one of these properties in a build profile: developmentClient to true (default), distribution to internal, android.buildType to apk, or android.gradleCommand to :app:assembleRelease, :app:assembleDebug, :app:assembleDebugOptimized (SDK 54+), or another Gradle command that produces an .apk.

Example eas.json APK build profiles

{ "build": { "preview": { "android": { "buildType": "apk" } }, "preview2": { "android": { "gradleCommand": ":app:assembleRelease" } }, "preview3": { "developmentClient": true }, "preview4": { "distribution": "internal" }, "production": {} } }

Custom caching with cache field in eas.json

The cache field on build profiles in eas.json can be used to configure caching for specific files and directories. Specified files will be saved to persistent storage after a successful build and restored on subsequent builds after JavaScript dependencies are installed. Restoring does not overwrite existing files. Changing the cache.key value will invalidate the cache. Changing any other property of the cache object will also invalidate the cache.

EAS Build npm cache server for JavaScript dependencies

EAS Build runs an npm cache server that can speed up downloading JavaScript dependencies for build jobs. By default, projects using npm or Yarn 2+ will use the cache. Yarn 1 (Classic) requires a workaround to use the cache. To disable the npm cache server, set the EAS_BUILD_DISABLE_NPM_CACHE environment variable to "1" in eas.json or in a job's env if using EAS Workflows.

Immutable lockfiles during build

By default, Node packages will be installed with the preferred package manager's immutable lockfile flag (for example, yarn --frozen-lockfile or npm ci). To disable this, set the EAS_NO_FROZEN_LOCKFILE environment variable to "1" in eas.json.

ccache configuration environment variables

EAS supports ccache configuration with these environment variables: EAS_USE_CACHE (set to 1 to enable both restoring and saving cache), EAS_RESTORE_CACHE (set to 1 to enable or 0 to disable cache restoration, overrides EAS_USE_CACHE), and EAS_SAVE_CACHE (set to 1 to enable or 0 to disable cache saving, overrides EAS_USE_CACHE).

EAS Workflows cache restoration and saving steps

For EAS Workflows, use eas/restore_cache and eas/save_cache steps to manage caching. The eas/restore_build_cache and eas/save_build_cache steps are equivalent to eas/restore_cache and eas/save_cache with automatic key generation based on hashFiles of the lock file.

Cache key matching sequence in EAS

When restoring a cache, the cache system follows a specific search sequence: First, it searches for an exact match to the cache key (automatically generated or explicitly provided). If no exact match is found, restore_keys will be checked sequentially for the most recent prefix matches. An exact match to the provided key is considered a direct cache hit and the cache is restored immediately. A partial match or match from restore_keys will restore the cache but may not perform as effectively.

Cache restrictions for GitHub runs

When a build is run from GitHub, caches get scoped to the branch the build is running from. A build can restore caches created in the current branch or the default branch (main or master).

Cache restrictions for EAS CLI runs

When a build is triggered from eas-cli, caches are scoped to the user running the build. User-scoped caches allow for isolation so that modifications to the build and its cache are not unintentionally shared during development or between users.

Default branch cache fallback behavior

If a build doesn't restore a user-scoped cache, it will automatically fallback to restoring caches published from GitHub builds triggered on the default branch. This allows builds to benefit from caches created by trusted sources even when no user-scoped cache exists yet.

Shared user cache behavior and risks

When a single user-actor is shared between multiple people (such as when using access tokens or triggering builds from GitHub Actions), user-scoped cache rules still apply. This means that builds operating under that shared account will no longer have isolated caches and run the risk of sharing unintended artifacts. To avoid this, it is recommended not to restore cache for production builds under a shared user, and to have designated jobs to only save clean, new caches.

Designated jobs for cache creation

You can configure a job to publish clean, new caches by disabling cache restoration and only saving the cache. This is done by setting EAS_RESTORE_CACHE to 0 and EAS_SAVE_CACHE to 1 for specific build profiles.

Cache key generation based on lock file

The cache key uses a hash of the package manager lock file to create a unique key based on your dependencies. When dependencies change, a new cache will be created while still allowing fallback to previous caches using restore_keys.

Restore key prefix matching behavior

A restore key like 'android-ccache-' matches any key that starts with that string. For example, both 'android-ccache-fd3052de' and 'android-ccache-a9b253ff' match the restore key. The cache with the most recent creation date would be used. The search order follows: exact hash match (android-ccache-${{ hashFiles('yarn.lock') }}), prefix match (android-ccache-), broader prefix match (android-).

Production build cache example configuration

Example eas.json configuration showing production builds with EAS_RESTORE_CACHE set to 0 and EAS_SAVE_CACHE set to 1 to create clean caches, while preview builds have EAS_USE_CACHE set to 1 to both restore and save cache.

Workflow cache saving from designated branch

Example workflow configuration that only saves cache from a specific job on the main branch. The build_production job uses if: ${{ github.ref_name == 'main' }} with EAS_RESTORE_CACHE set to 0 and EAS_SAVE_CACHE set to 1. Note that setting EAS_SAVE_CACHE to 1 does not make cache saving exclusive to this job, other jobs with the same environment variable can still save and overwrite the cache.

.easignore file purpose and location

The .easignore file defines which files EAS should ignore when uploading your project to EAS Build servers. It is created in the root of your project.

.easignore prioritizes over .gitignore

By default, EAS CLI refers to the .gitignore file to determine which files to ignore. If a .easignore file is created, the EAS CLI prioritizes it over .gitignore. When creating .easignore, you should include all files and directories from .gitignore and add additional files you want to ignore.

Benefit of ignoring unnecessary files in .easignore

Ignoring unnecessary files can help reduce the app's archive size and upload time to EAS Build servers.

EAS Build runs Prebuild if native directories missing

If your project does not contain android and ios directories, EAS Build will run Prebuild to generate these native directories before compilation.

Include files not in source control with .easignore

You can use the .easignore file to include files with your EAS Build upload that are not committed to source control by adding them with a ! prefix. The ! prefixed file should be last so it takes precedence over any prior rules that would ignore it. This is useful for custom scripts that generate temporary files needed for the build process.

.easignore example with native directories and temporary files

Example .easignore file: ``` # Copy everything from your .gitignore file here /android /ios # Include a file not in source control !temp_file.json ``` This shows ignoring native directories and including a temporary file not in source control.

Give your agent this brain