eas/environment-variables

94 notes in this subject, read out of this brain and free to use. This is page 2 of 2.

Create custom environment with EAS CLI

Use the eas env:set command with your custom environment name in place of the default environment parameter. For example: eas env:set --name EXPO_PUBLIC_API_URL --value https://example.app/staging --environment staging --visibility plaintext

Accessing environment variables in EAS Build jobs

After creating an environment variable, you can read it on subsequent EAS Build jobs with process.env.VARIABLE_NAME from Node.js or in shell scripts as $VARIABLE_NAME.

Dynamically setting environment variables during job execution

You can set environment variables dynamically during job execution using the set-env command. The set-env executable is available in the PATH on EAS Build workers and can be used to set environment variables that will be visible in the next build phases. For example, run $ set-env EXAMPLE_ENV 'example value' in an EAS Build hook and the environment variable will be available until the end of the build job.

Using eas env:exec command for non-secret variables

One way to supply non-secret EAS environment variables to other EAS commands is to use the eas env:exec command. For example: $ eas env:exec --environment production 'echo $APP_VARIANT' or $ eas env:exec --environment production 'npx sentry-expo-upload-sourcemaps dist'

Secret variables not available during EAS Update process

Secret variables will not be available during the EAS Update process because they are not readable outside of EAS servers.

Expo CLI substitution of EXPO_PUBLIC_ variables

Expo CLI will substitute prefixed variables in code (for example, process.env.EXPO_PUBLIC_VARNAME) with the corresponding plain text and sensitive environment variable values set on EAS servers for the environment specified with the --environment flag.

Built-in environment variables in EAS Build

EAS Build exposes the following built-in environment variables to each job, not available when evaluating app.config.js locally: CI=1 (indicates CI environment), EAS_BUILD=true (indicates EAS Build environment), EAS_BUILD_PLATFORM (either android or ios), EAS_BUILD_RUNNER (either eas-build for cloud builds or local-build-plugin for local builds), EAS_BUILD_ID (the build ID as a UUID), EAS_BUILD_PROFILE (the name of the build profile from eas.json), EAS_BUILD_PROJECT_ID (the EAS project ID as a UUID), EAS_BUILD_GIT_COMMIT_HASH (the Git commit hash), EAS_BUILD_NPM_CACHE_URL (npm cache URL), EAS_BUILD_MAVEN_CACHE_URL (Maven cache URL), EAS_BUILD_COCOAPODS_CACHE_URL (CocoaPods cache URL), EAS_BUILD_USERNAME (username of the user initiating the build, undefined for bot users), EAS_BUILD_WORKINGDIR (remote directory path with the project), EAS_BUILD_DISABLE_BUNDLE_JAVASCRIPT_STEP (set to 1 to skip early JavaScript bundling check), EAS_BUILD_DISABLE_NPM_CACHE (set to 1 to disable npm cache server), EAS_BUILD_DISABLE_MAVEN_CACHE (set to 1 to disable Maven cache server), EAS_BUILD_DISABLE_COCOAPODS_CACHE (set to 1 to disable CocoaPods cache server).

Example: eas update command with environment flag

$ eas update --environment production

Using environment variables with EAS Update

In SDK 55 or later, the --environment flag is required when running eas update. The environment variables from the specified EAS environment will be used during the update process. For projects using SDK 54 or earlier, eas update falls back to local .env files when the --environment flag is omitted. When the --environment flag is used, only environment variables from the specified EAS environment will be used and .env files in the project will not be used.

Secret environment variables not available during build configuration resolution

Environment variables of secret type are not available during build configuration resolution in EAS CLI because they are not readable outside of EAS servers.

Job environment resolution in EAS Workflows

Which EAS environment variables a job can read depends on its environment setting: production (the default), preview, or development. Only variables assigned to that environment are exposed. Each job type resolves its environment differently: build jobs infer it from the build profile's environment in eas.json; submit jobs inherit it from the submitted build; maestro and maestro-cloud jobs default to preview; other jobs default to production. Set jobs.<job_id>.environment explicitly to override the default.

Environment variable precedence in EAS Workflows

When the same variable name is defined in multiple sources, precedence from highest to lowest is: Job env (variables you set on the job with the env key, plain text defined in workflow file), eas.json build profile env (for build jobs, the env from the profile selected by params.profile), and EAS environment variables (stored on EAS for the job's environment: production, preview, or development). The worker also sets additional variables like EAS_BUILD_ID and CI. Avoid naming your own variables with the EAS_ prefix to prevent shadowing.

Environment variable interpolation syntax in EAS Workflows

Environment variables in EAS Workflows can be read in two ways: with the ${{ env.NAME }} interpolation syntax anywhere a job interpolates values (in params, if, env, and run), or as standard shell variables ($NAME) or through process.env.NAME from inside a run step.

Defining custom environment variables in EAS Workflows jobs

To define your own variables, use the env key on a job. Values can reference other context properties like ${{ github.sha }}.

Built-in environment variables provided by EAS Workflows workers

Workers provide additional variables on every job that runs on a virtual machine, such as EAS_BUILD_ID, EAS_BUILD_PROJECT_ID, and CI. These are read at runtime from within a run step. Workers also expose standard toolchain variables such as HOME, PATH, LANG, ANDROID_HOME, ANDROID_SDK_ROOT, and JAVA_HOME. Their exact values depend on the worker image and are subject to change.

app_store_connect context in EAS Workflows

The app_store_connect context is present only for workflows triggered by an App Store Connect event. It contains: app (with id), build_upload (with id, state: awaiting_upload/processing/failed/complete, cf_bundle_version, cf_bundle_short_version_string, platform, uploaded_date, created_date, build id), app_version (with id and state), external_beta (with id and state), and beta_feedback (with id, type: crash/screenshot, url).

workflow context in EAS Workflows

The workflow context contains: id (ID of the workflow run), name (name of the workflow), filename (name of the workflow file), and url (URL of the run on the EAS dashboard).

metadata context in EAS Workflows

The metadata context contains: buildProfile (build profile from eas.json), appVersion (app version), appBuildVersion (build number for iOS or version code for Android), sdkVersion (Expo SDK version), runtimeVersion (runtime version for EAS Update), gitCommitHash (git commit the build ran against), and distribution (store or internal). This context is populated for build jobs and is an empty object for job types without build metadata.

Context variables available in EAS Workflows

EAS Workflows jobs can interpolate several context objects using the ${{ ... }} syntax: env (environment variables), github (fields from the GitHub event that triggered the workflow), inputs (record of inputs from workflow_dispatch), needs (upstream jobs listed in needs with their status and outputs), after (upstream jobs listed in after with their status and outputs), steps (steps in the current job keyed by step id with outputs), metadata (metadata about the associated build for build jobs), workflow (information about the current workflow run), and app_store_connect (information about App Store Connect entities for App Store Connect triggered workflows).

Secret redaction in EAS Workflows logs

Values interpolated from EAS environment variables of type secret or sensitive are redacted in workflow logs.

Interpolation timing and variable availability in EAS Workflows

Interpolation happens in two places with different variable availability: Job configuration (params, if, outputs, and the value of env itself) is interpolated before the job is dispatched to a worker. At this point, env contains EAS environment variables for the resolved environment, but not additional worker variables or the job's own env values. Run commands are interpolated on the worker, where env reflects the full runtime environment: EAS environment variables, the job's env, and additional variables. This means read variables like EAS_BUILD_ID inside a run step rather than in a job's params. Inside a run step, ${{ env.EAS_BUILD_ID }} and $EAS_BUILD_ID are equivalent.

${{ env }} context availability in EAS Workflows

The ${{ env }} context is available within a job's context, not at the top level of the workflow. You can use it in a job's params, if, env, outputs, and run, but not in the top-level on triggers.

Example: read EAS environment variables in workflow params

```yaml jobs: notify: type: slack params: # Reads the SLACK_WEBHOOK_URL EAS environment variable. webhook_url: ${{ env.SLACK_WEBHOOK_URL }} message: 'Deploy finished' ``` This example shows using ${{ env.NAME }} in job params to access EAS environment variables.

Example: print environment variables in EAS Workflows

```yaml name: Print environment jobs: print: steps: # Interpolated before the command runs. - run: echo "Project: ${{ env.EAS_BUILD_PROJECT_ID }}" # Read from the shell environment at runtime. - run: echo "Project: $EAS_BUILD_PROJECT_ID" ``` This example shows both interpolation syntax (${{ env.NAME }}) and shell variable syntax ($NAME) for reading environment variables.

set-env command for sharing values between steps in EAS Workflows

Use the set-env command to compute a value in one step and read it in later steps of the same job. The command is available on the worker's PATH. It is the environment-variable counterpart to set-output: set-output exposes a named job output, while set-env exposes an environment variable to the job's subsequent steps. set-env only affects later steps, not the step that executes it.

Example: use app_store_connect context

```yaml on: app_store_connect: build_upload: states: - complete jobs: notify: type: slack params: webhook_url: ${{ env.SLACK_WEBHOOK_URL }} message: | Upload complete for app: ${{ app_store_connect.app.id }} Upload state: ${{ app_store_connect.build_upload.state }} ``` This example shows accessing app_store_connect context fields when a workflow is triggered by an App Store Connect event.

Example: use workflow context in Slack notification

```yaml jobs: notify: type: slack params: message: | Workflow run completed: ${{ workflow.name }} View details: ${{ workflow.url }} ``` This example shows accessing workflow context fields (name and url) in job parameters.

Example: generate and use environment variables in EAS Workflows

```yaml jobs: my_job: steps: - run: set-env GENERATED_TAG "v$(date +%Y%m%d)" # `set-env` only affects later steps, so the value is available here. - run: echo "Tag is $GENERATED_TAG" ``` This example shows using set-env to compute a value in one step and access it in a later step.

Example: define and use custom environment variables in EAS Workflows

```yaml jobs: my_job: env: APP_VARIANT: staging COMMIT: ${{ github.sha }} steps: - run: echo "Building $APP_VARIANT at $COMMIT" ``` This example shows defining custom environment variables on a job, with one variable referencing a context property.

Example: read step outputs in EAS Workflows

```yaml jobs: my_job: steps: - id: step_1 run: set-output my_greeting "hello" - run: echo "${{ steps.step_1.outputs.my_greeting }}" ``` This example shows accessing outputs from a previous step using the steps context.

Example: read needs context in EAS Workflows

```yaml jobs: notify: needs: [build] steps: - run: echo "Build status: ${{ needs.build.status }}" ``` This example shows accessing upstream job status from the needs context.

Use environment variables in workflows

Reference environment variables in workflow files using the syntax ${{ env.VARIABLE_NAME }}. Create environment variables in the Expo dashboard under account settings > environment variables, associated with a specific environment name used in the workflow.

Environment variables in workflows

Workflows support EAS environment variables and inline env values. Environment variables can be referenced using the syntax ${{ env.VARIABLE_NAME }}.

EAS environment variables scoped by environment

EAS environment variables are scoped to an environment: production, preview, or development. A job only sees variables from the environment set by its environment key, which defaults to production. If a variable is empty in a job, confirm the variable exists in the environment the job uses, or set the job's environment to match where the variable is defined.

Give your agent this brain