This documentation is available as Markdown for AI agents and LLMs. See the full Markdown index or append .md to any documentation URL.

EAS 工作流任务中可用的环境变量参考，包括 env 上下文和额外的工作变量。

每个工作流任务都会在一个有一组环境变量可用的工作节点上运行。你可以用两种方式读取这些变量：

🌐 Every workflow job runs on a worker that has a set of environment variables available to it. You can read these variables in two ways:

• 使用 ${{ env.NAME }} 插值语法，任何地方的作业都会插入值（例如，在 params、if、env 和 run 中）。
• 作为标准的 shell 变量（$NAME）或者通过 run 步骤里的 process.env.NAME。

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"

优先级

🌐 Precedence

作业中可用的变量来自三个来源。当同一个名字在多个来源中都有定义时，列表中靠前的那个优先：

🌐 The variables available in a job are merged from three sources. When the same name is defined in more than one source, the one higher in this list wins:

除此之外，工作进程会设置一些额外变量，比如 EAS_BUILD_ID 和 CI。避免用 EAS_ 前缀给自己的变量命名，以免覆盖它们。

🌐 On top of these, the worker sets a number of additional variables such as EAS_BUILD_ID and CI. Avoid naming your own variables with the EAS_ prefix so these don't shadow them.

工作环境

🌐 The job environment

作业可以读取哪些 EAS 环境变量取决于它的 环境：production（默认）、preview 或 development。只有分配给该环境的变量会对作业可见。

🌐 Which EAS environment variables a job can read depends on its environment: production (the default), preview, or development. Only variables assigned to that environment are exposed to the job.

每个工作对它的环境处理方式都不同：

🌐 Each job resolves its environment differently:

• build 作业从 eas.json 中构建配置的 environment 推断出来。
• submit 作业会从提交的构建继承它。
• maestro 和 maestro-cloud 的工作默认是 preview。
• 其他工作默认是 production。

明确设置 jobs.<job_id>.environment 来覆盖默认值，并保持任务与其配对的构建配置同步。有关为任务选择环境的更多详情，请参阅 在 EAS 工作流程中使用环境变量。

${{ env }} 上下文

🌐 The ${{ env }} context

${{ env }} 上下文 是按名称键入的环境变量记录。它可以在作业的上下文中使用，但不能在工作流的顶层使用。例如，你可以在作业的 params、if、env、outputs 和 run 中使用它，但不能在顶层的 on 触发器中使用。

🌐 The ${{ env }} context is a record of environment variables keyed by name. It is available within a job's context, not at the top level of the workflow. For example, you can use it in a job's params, if, env, outputs, and run, but not in the top-level on triggers.

jobs:
  notify:
    type: slack
    params:
      # Reads the SLACK_WEBHOOK_URL EAS environment variable.
      webhook_url: ${{ env.SLACK_WEBHOOK_URL }}
      message: 'Deploy finished'

插值发生在两个地方，这会改变 ${{ env.NAME }} 能解析的内容：

🌐 Interpolation happens in two places, which changes what ${{ env.NAME }} can resolve:

• 作业配置（params、if、outputs 以及 env 自身的值）会在作业派发给工作节点之前进行插值。此时，env 包含你为解析后的 环境 设置的 EAS 环境变量。额外的工作节点变量和作业自身的 env 值还不能在这里使用。
• run 命令 会在工作节点上被插入，其中 env 反映了完整的运行时环境：EAS 环境变量、作业的 env 以及 其他变量。

因此，应在 run 步骤中读取像 EAS_BUILD_ID 这样的变量，而不是在作业的 params 中。在 run 步骤中，${{ env.EAS_BUILD_ID }} 和 $EAS_BUILD_ID 是等价的。

🌐 Because of this, 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.

信息 来自 EAS 环境变量（类型为 secret 或 sensitive）的插值值在工作流日志中会被隐藏。

上下文变量

🌐 Context variables

环境变量并不是工作可以插值的唯一内容。同样的 ${{ ... }} 语法还可以访问描述工作流运行的几个上下文对象。上面提到的 env 上下文只是其中之一。其他的在下面有文档说明。有关插值语法和可用的 上下文函数（例如 toJSON、fromJSON 和 success()），请参见 语法。

🌐 Environment variables are not the only thing a job can interpolate. The same ${{ ... }} syntax exposes several context objects that describe the workflow run. The env context covered above is one of them. The others are documented below. For the interpolation syntax and the available context functions such as toJSON, fromJSON, and success(), see Syntax.

信息 要查看运行时任何上下文的完整内容，请使用 toJSON 打印它。例如，run: echo '${{ toJSON(github) }}'。

github

触发工作流的 GitHub 事件中的字段。当你用 eas workflow:run 启动运行时，event_name 是 workflow_dispatch，其他字段都是空的。

🌐 Fields from the GitHub event that triggered the workflow. When you start a run with eas workflow:run, event_name is workflow_dispatch and the other fields are empty.

github {
  triggering_actor,   // User who triggered the run, e.g. jonexpo
  event_name,         // 'pull_request', 'push', 'schedule', or 'workflow_dispatch'
  sha,                // Commit SHA
  ref,                // Full ref, e.g. refs/heads/main
  ref_name,           // Short ref, e.g. main
  ref_type,           // 'branch', 'tag', or 'other'
  commit_message,     // Only for push and schedule events
  label,              // Label name, for pull_request_labeled events
  repository,         // e.g. expo/expo
  repository_owner,   // e.g. expo
  event {             // Full GitHub webhook payload
    action,
    head_commit { message, id },   // Only for push and schedule events
    pull_request {
      number,
      title,
      body,
      state,          // 'open' or 'closed'
      draft,
      merged,
      html_url,
      user { login },
      labels,         // Array of { name }
      head { ref, sha },   // Source branch
      base { ref, sha },   // Target branch
      created_at,
      updated_at,
      merged_at,
      // ... and other fields from the GitHub Pull Request webhook payload
    },
    inputs,           // workflow_dispatch inputs
    schedule,         // Cron expression, for scheduled runs
    number,
  }
}

event 对象包含完整的 GitHub webhook 负载。有关详细字段参考和示例，请参见语法指南中的 github。

🌐 The event object contains the full GitHub webhook payload. For a detailed field reference and examples, see github in the Syntax guide.

inputs

当你使用 workflow_dispatch 手动启动工作流时提供的输入记录。如果工作流是通过其他方式触发的，则为空。

🌐 A record of the inputs provided when you start the workflow manually with workflow_dispatch. Empty when the workflow is triggered another way.

jobs:
  greet:
    steps:
      - run: echo "Hello, ${{ inputs.name }}!"

needs

当前作业的 needs 中列出的上游作业记录。每条记录都会提供作业的 status（success、failure 或 skipped）以及它的 outputs。

🌐 A record of the upstream jobs listed in the current job's needs. Each entry provides the job's status (success, failure, or skipped) and its outputs.

jobs:
  notify:
    needs: [build]
    steps:
      - run: echo "Build status: ${{ needs.build.status }}"

after

当前作业的 after 中列出的上游作业记录，无论它们是否成功。每个条目都提供与 needs 相同的 status 和 outputs 结构。

🌐 A record of the upstream jobs listed in the current job's after, whether or not they succeeded. Each entry provides the same status and outputs shape as needs.

jobs:
  notify:
    after: [build]
    steps:
      - run: echo "Build status: ${{ after.build.status }}"

steps

当前作业中各步骤的记录，以步骤 id 为键。每个条目都通过 set-output 函数暴露 outputs 集。这个上下文只在作业的步骤中可用。

🌐 A record of the steps in the current job, keyed by step id. Each entry exposes the outputs set with the set-output function. This context is only available within a job's steps.

jobs:
  my_job:
    steps:
      - id: step_1
        run: set-output my_greeting "hello"
      - run: echo "${{ steps.step_1.outputs.my_greeting }}"

metadata

与作业相关的构建元数据。对于 build 作业会填充该信息，而对于没有构建元数据的作业类型（例如自定义作业），则是一个空对象（{}）。

🌐 Metadata about the build associated with the job. It is populated for build jobs and is an empty object ({}) for job types without build metadata, such as custom jobs.

metadata {
  buildProfile,     // Build profile from eas.json, e.g. production
  appVersion,       // App version, e.g. 1.0.0
  appBuildVersion,  // Build number (iOS) or version code (Android)
  sdkVersion,       // Expo SDK version, e.g. 54.0.0
  runtimeVersion,   // Runtime version for EAS Update
  gitCommitHash,    // Git commit the build ran against
  distribution,     // 'store' or 'internal'
}

workflow

关于当前工作流程运行的信息。

🌐 Information about the current workflow run.

workflow {
  id,        // ID of the workflow run
  name,      // Name of the workflow
  filename,  // Name of the workflow file, e.g. deploy.yml
  url,       // URL of the run on the EAS dashboard
}

jobs:
  notify:
    type: slack
    params:
      message: |
        Workflow run completed: ${{ workflow.name }}
        View details: ${{ workflow.url }}

app_store_connect

有关与该运行相关的 App Store Connect 实体的信息。只有在由 App Store Connect 事件 触发的工作流中才会有这个上下文。

🌐 Information about the App Store Connect entities associated with the run. This context is present only for workflows triggered by an App Store Connect event.

app_store_connect {
  app { id },
  build_upload {
    id,
    state,             // 'awaiting_upload', 'processing', 'failed', or 'complete'
    cf_bundle_version,
    cf_bundle_short_version_string,
    platform,
    uploaded_date,
    created_date,
    build { id },
  },
  app_version { id, state },
  external_beta { id, state },
  beta_feedback {
    id,
    type,              // 'crash' or 'screenshot'
    url,
  },
}

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 }}

有关填充每个字段的事件域和完整示例，请参见语法指南中的 app_store_connect。

🌐 For the event domains that populate each field and full examples, see app_store_connect in the Syntax guide.

额外的环境变量

🌐 Additional environment variables

除了你设置的变量之外，工作进程在每个在虚拟机（VM）上运行的作业中都会提供一些变量，比如 EAS_BUILD_ID、EAS_BUILD_PROJECT_ID 和 CI。它们是在运行时读取的，所以可以在 run 步骤中引用它们。完整列表请参见 内置环境变量。

🌐 In addition to the variables you set, the worker provides a number of variables on every job that runs on a virtual machine (VM), such as EAS_BUILD_ID, EAS_BUILD_PROJECT_ID, and CI. They are read at runtime, so reference them from within a run step. For the full list, see Built-in environment variables.

工作进程还会暴露标准的工具链变量，比如 HOME、PATH、LANG、ANDROID_HOME、ANDROID_SDK_ROOT 和 JAVA_HOME。它们的具体值取决于工作进程的 镜像，而且可能会发生变化。

🌐 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.

在作业中设置环境变量

🌐 Setting environment variables in a job

要定义你自己的变量，请在作业上使用env键。数值可以引用其他上下文属性。

🌐 To define your own variables, use the env key on a job. Values can reference other context properties.

jobs:
  my_job:
    env:
      APP_VARIANT: staging
      COMMIT: ${{ github.sha }}
    steps:
      - run: echo "Building $APP_VARIANT at $COMMIT"

在同一个作业的后续步骤中共享一个值

🌐 Share a value with later steps in the same job

使用 set-env 命令可以一步计算一个值，并在同一个作业的后续步骤中读取它。该命令可以在工作节点的 PATH 上使用。它是 set-output 的环境变量对应功能：set-output 用于暴露命名的作业输出，而 set-env 则将一个环境变量暴露给作业的后续步骤。

🌐 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's 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.

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"