EAS 工作流程的语法

EAS Workflows 配置文件语法的参考指南。

工作流是由一个或多个任务组成的可配置自动化流程。你必须创建一个 YAML 文件来定义你的工作流配置。

🌐 A workflow is a configurable automated process made up of one or more jobs. You must create a YAML file to define your workflow configuration.

要开始使用工作流，请参阅 开始使用 EAS 工作流 或查看 示例 以获取完整的工作流配置。

🌐 To get started with workflows, see Get Started with EAS Workflows or see Examples for complete workflow configurations.

工作流文件

🌐 Workflow files

工作流文件使用 YAML 语法，并且必须具有 .yml 或 .yaml 文件扩展名。如果你是 YAML 新手并想了解更多，请参阅 在 Y 分钟内学习 YAML。

🌐 Workflow files use YAML syntax and must have either a .yml or .yaml file extension. If you're new to YAML and want to learn more, see Learn YAML in Y minutes.

工作流文件位于项目中的 .eas/workflows 目录下。.eas 目录应与你的 eas.json 文件位于同一层级。

🌐 Workflow files are located in the .eas/workflows directory in your project. The .eas directory should be at the same level as your eas.json file.

例如：

🌐 For example:

配置参考

🌐 Configuration reference

以下是工作流配置文件语法的参考。

🌐 Below is a reference for the syntax of the workflow configuration file.

name

工作流的友好名称。它显示在 EAS 仪表板的工作流列表页面上，并且是工作流详情页面的标题。

🌐 The human-friendly name of the workflow. This is displayed on the EAS dashboard on the workflows list page and is the title of the workflow's detail page.

name: My workflow

on

on 键定义了哪些 GitHub 事件会触发工作流。任何工作流都可以通过 eas workflow:run 命令触发，而不管 on 键的设置如何。

🌐 The on key defines which GitHub events trigger the workflow. Any workflow can be triggered with the eas workflow:run command, regardless of the on key.

on:
  # Trigger on pushes to main branch
  push:
    branches:
      - main
  # And on pull requests starting with 'version-'
  pull_request:
    branches:
      - version-*

on.push

当拉取请求带有匹配标签时运行你的工作流程。

🌐 Runs your workflow when you push a commit to matching branches and/or tags.

使用 branches 列表时，只有在推送到指定分支时才会触发工作流。例如，如果你使用 branches: ['main']，只有推送到 main 分支才会触发工作流。支持通配符。通过使用 ! 前缀，你可以指定要忽略的分支（你仍然需要至少提供一个没有该前缀的分支模式）。

🌐 With the branches list, you can trigger the workflow only when those specified branches are pushed to. For example, if you use branches: ['main'], only pushes to the main branch will trigger the workflow. Supports globs. By using the ! prefix you can specify branches to ignore (you still need to provide at least one branch pattern without it).

使用 tags 列表，你可以仅在推送这些指定标签时触发工作流。例如，如果你使用 tags: ['v1']，只有推送 v1 标签才会触发工作流。支持通配符。通过使用 ! 前缀，你可以指定要忽略的标签（你仍然需要至少提供一个不带前缀的标签模式）。

🌐 With the tags list, you can trigger the workflow only when those specified tags are pushed. For example, if you use tags: ['v1'], only the v1 tag being pushed will trigger the workflow. Supports globs. By using the ! prefix you can specify tags to ignore (you still need to provide at least one tag pattern without it).

使用 paths 列表时，只有当对匹配指定路径的文件进行更改时才会触发工作流。例如，如果使用 paths: ['apps/mobile/**']，只有对 apps/mobile 目录中的文件进行更改才会触发工作流。支持通配符。默认情况下，对任何路径的更改都会触发工作流。

🌐 With the paths list, you can trigger the workflow only when changes are made to files matching the specified paths. For example, if you use paths: ['apps/mobile/**'], only changes to files in the apps/mobile directory will trigger the workflow. Supports globs. By default, changes to any path will trigger the workflow.

当既没有提供 branches 也没有提供 tags 时，branches 默认为 ['*']，tags 默认为 []，这意味着工作流将在所有分支的推送事件时触发，但不会在标签推送时触发。如果只提供了两个列表中的一个，则另一个默认为 []。

🌐 When neither branches nor tags are provided, branches defaults to ['*'] and tags defaults to [], which means the workflow will trigger on push events to all branches and will not trigger on tag pushes. If only one of the two lists is provided the other defaults to [].

on:
  push:
    branches:
      - main
      - feature/**
      - !feature/test-** # other branch names and globs


    tags:
      - v1
      - v2*
      - !v2-preview** # other tag names and globs


    paths:
      - apps/mobile/**
      - packages/shared/**
      - !**/*.md # ignore markdown files

on.pull_request

当你创建或更新针对匹配分支之一的拉取请求时，运行你的工作流。

🌐 Runs your workflow when you create or update a pull request that targets one of the matching branches.

使用 branches 列表时，你可以仅在指定的分支作为拉取请求目标时触发工作流。例如，如果你使用 branches: ['main']，则只有合并到主分支的拉取请求会触发工作流。支持通配符。如果未提供，则默认为 ['*']，这意味着工作流将在所有分支的拉取请求事件上触发。通过使用 ! 前缀，你可以指定要忽略的分支（仍然需要至少提供一个没有该前缀的分支模式）。

🌐 With the branches list, you can trigger the workflow only when those specified branches are the target of the pull request. For example, if you use branches: ['main'], only pull requests to merge into the main branch will trigger the workflow. Supports globs. Defaults to ['*'] when not provided, which means the workflow will trigger on pull request events to all branches. By using the ! prefix you can specify branches to ignore (you still need to provide at least one branch pattern without it).

使用 types 列表，你可以仅在指定的拉取请求事件类型上触发工作流。例如，如果使用 types: ['opened']，则只有 pull_request.opened 事件（在首次打开拉取请求时发送）会触发工作流。如果未提供，则默认为 ['opened', 'reopened', 'synchronize']。支持的事件类型有：

🌐 With the types list, you can trigger the workflow only on the specified pull request event types. For example, if you use types: ['opened'], only the pull_request.opened event (sent when a pull request is first opened) will trigger the workflow. Defaults to ['opened', 'reopened', 'synchronize'] when not provided. Supported event types:

• opened
• reopened
• synchronize
• labeled

使用 paths 列表时，只有当对匹配指定路径的文件进行更改时才会触发工作流。例如，如果使用 paths: ['apps/mobile/**']，只有对 apps/mobile 目录中的文件进行更改才会触发工作流。支持通配符。默认情况下，对任何路径的更改都会触发工作流。

🌐 With the paths list, you can trigger the workflow only when changes are made to files matching the specified paths. For example, if you use paths: ['apps/mobile/**'], only changes to files in the apps/mobile directory will trigger the workflow. Supports globs. By default, changes to any path will trigger the workflow.

on:
  pull_request:
    branches:
      - main
      - feature/**
      - !feature/test-** # other branch names and globs


    types:
      - opened
      # other event types

    paths:
      - apps/mobile/**
      - packages/shared/**
      - !**/*.md # ignore markdown files

on.pull_request_labeled

当匹配分支上发生拉取请求事件时运行你的工作流程。

🌐 Runs your workflow when a pull request is labeled with a matching label.

使用 labels 列表，你可以指定哪些标签在分配给拉取请求时会触发工作流。例如，如果你使用 labels: ['Test']，只有将 Test 标签添加到拉取请求时才会触发工作流。如果未提供，则默认为 []，这意味着没有标签会触发工作流。

🌐 With the labels list, you can specify which labels, when assigned to your pull request, will trigger the workflow. For example, if you use labels: ['Test'], only labeling a pull request with the Test label will trigger the workflow. Defaults to [] when not provided, which means no labels will trigger the workflow.

你也可以直接向 on.pull_request_labeled 提供匹配标签的列表，以简化语法。

🌐 You can also provide a list of matching labels directly to on.pull_request_labeled for simpler syntax.

on:
  pull_request_labeled:
    labels:
      - Test
      - Preview
      # other labels

或者：

🌐 Alternatively:

on:
  pull_request_labeled:
    - Test
    - Preview
    # other labels

on.schedule.cron

使用 unix-cron 语法按计划运行你的工作流程。你可以使用 crontab guru 及其 示例 来生成 cron 字符串。

🌐 Runs your workflow on a schedule using unix-cron syntax. You can use crontab guru and their examples to generate cron strings.

• 计划工作流只会在仓库的默认分支上运行。在许多情况下，这意味着位于 main 分支的工作流文件中的定时任务会被调度，而功能分支中的工作流文件中的定时任务则不会被调度。
• 在高负载期间，计划的工作流可能会延迟。高负载时间包括每小时的开始。在极少数情况下，任务可能会被跳过或运行多次。请确保你的工作流是幂等的，并且不会产生有害的副作用。
• 一个工作流程可以有多个 cron 计划。
• 计划的工作流在 GMT 时区运行。

on:
  schedule:
    - cron: '0 0 * * *' # Runs at midnight GMT every day

on.workflow_dispatch.inputs

定义在使用 eas workflow:run 命令手动触发工作流时可以提供的输入。这使你可以创建可参数化的工作流，每次运行时可以接受不同的值。

🌐 Defines inputs that can be provided when manually triggering a workflow using the eas workflow:run command. This allows you to create parameterized workflows that can accept different values each time they run.

on:
  workflow_dispatch:
    inputs:
      name:
        type: string
        required: false
        description: 'Name of the person to greet'
        default: 'World'
      choice_example:
        type: choice
        options:
          - to be
          - not to be
        required: true

提供输入

🌐 Providing inputs

运行包含输入的工作流时，你可以通过多种方式提供输入：

🌐 When running a workflow with inputs, you can provide them in several ways:

1. 命令行标志：

   Terminal

   Copy

   - eas workflow:run .eas/workflows/deploy.yml -F environment=production -F debug=true -F version=1.2.3

2. 通过标准输入传输 JSON：

   Terminal

   Copy

   - echo '{"environment": "production", "debug": true, "version": "1.2.3"}' | eas workflow:run .eas/workflows/deploy.yml

3. 交互式提示：如果缺少必要的输入，并且你没有使用 --non-interactive，CLI 会提示你输入这些内容：

   Terminal

   Copy

   - eas workflow:run .eas/workflows/deploy.yml

用法

🌐 Usage

在你的工作流作业中，可以通过 ${{ inputs.<input_name> }} 语法使用输入值：

on:
  workflow_dispatch:
    inputs:
      name:
        type: string
        required: true
        description: 'Name of the person to greet'

jobs:
  deploy:
    steps:
      - name: Deploy to environment
        run: |
          echo "Hello, ${{ inputs.name }}!"

          # Note: you can use `||` to provide a default value
          #       for non-eas-workflow:run-run workflows.
          echo "Hello, ${{ inputs.name || 'World' }}!"

jobs

工作流程运行由一个或多个作业组成。

🌐 A workflow run is made up of one or more jobs.

jobs:
  job_1:
    # ...
  job_2:
    # ...

jobs.<job_id>

每个作业必须有一个 ID。该 ID 在工作流中应唯一，并且可以包含字母数字字符和下划线。例如，在以下 YAML 中的 my_job：

🌐 Each job must have an ID. The ID should be unique within the workflow and can contain alphanumeric characters and underscores. For example, my_job in the following YAML:

jobs:
  my_job:
    # ...

jobs.<job_id>.name

工作流详细信息页面上显示的作业的人性化名称。

🌐 The human-friendly name of the job displayed on the workflow's detail page.

jobs:
  my_job:
    name: Build app

jobs.<job_id>.environment

为作业设置 EAS 环境变量 环境。有三种可能的值：

🌐 Sets the EAS environment variable environment for the job. There are three possible values:

• production（默认）
• preview
• development

environment 键在所有职位上都可用。

🌐 The environment key is available on all jobs.

jobs:
  my_job:
    environment: production | preview | development

jobs.<job_id>.env

为作业设置环境变量。该属性适用于所有运行虚拟机的作业（除预打包的 require-approval、doc、get-build 和 slack 作业之外的所有作业）。

🌐 Sets environment variables for the job. The property is available on all jobs running a VM (all jobs except for the pre-packaged require-approval, doc, get-build and slack jobs).

jobs:
  my_job:
    env:
      APP_VARIANT: staging
      RETRY_COUNT: 3
      PREV_JOB_OUTPUT: ${{ needs.previous_job.outputs.some_output }}

jobs.<job_id>.defaults.run.working_directory

为作业中的所有步骤设置运行命令的目录。

🌐 Sets the directory to run commands in for all steps in the job.

jobs:
  my_job:
    defaults:
      run:
        working_directory: ./my-app
    steps:
      - name: My first step
        run: pwd # prints: /home/expo/workingdir/build/my-app

defaults

用作工作流配置中定义的所有作业的默认值的参数。

🌐 Parameters to use as defaults for all jobs defined in the workflow configuration.

defaults.run.working_directory

运行脚本的默认工作目录。像 "./assets" 或 "assets" 这样的相对路径会从应用的基础目录解析。

🌐 Default working directory to run the scripts in. Relative paths like "./assets" or "assets" are resolved from the app's base directory.

defaults.tools

此工作流配置中定义的作业应使用的工具的具体版本。请遵循每个工具的文档以获取可用值。

🌐 Specific versions of tools that should be used for jobs defined in this workflow configuration. Follow each tool's documentation for available values.

使用 defaults.tools 的工作流程示例：

🌐 Example of workflow using defaults.tools:

name: Set up custom versions
defaults:
  tools:
    node: latest
    yarn: '2'
    corepack: true
    pnpm: '8'
    bun: '1.0.0'
    fastlane: 2.224.0
    cocoapods: 1.12.0

on:
  push:
    branches: ['*']

jobs:
  setup:
    steps:
      - name: Check Node version
        run: node --version # should print a concrete version, like 23.9.0
      - name: Check Yarn version
        run: yarn --version # should print a concrete version, like 2.4.3

concurrency

并发控制的配置。目前仅允许为同一分支的工作流设置 cancel_in_progress。

🌐 Configuration for concurrency control. Currently only allows setting cancel_in_progress for same-branch workflows.

concurrency:
  cancel_in_progress: true
  group: ${{ workflow.filename }}-${{ github.ref }}

控制流

🌐 Control flow

你可以使用 needs 和 after 关键字来控制作业的运行时间。此外，你还可以使用 if 关键字来根据条件控制作业是否应该运行。

🌐 You can control when a job runs with the needs and after keywords. In addition, you can use the if keyword to control whether a job should run based on a condition.

jobs.<job_id>.needs

作业 ID 列表，这些作业必须先成功完成，然后此作业才会运行。

🌐 A list of job IDs whose jobs must complete successfully before this job will run.

jobs:
  test:
    steps:
      - uses: eas/checkout
      - uses: eas/use_npm_token
      - uses: eas/install_node_modules
      - name: tsc
        run: yarn tsc
  build:
    needs: [test] # This job will only run if the 'test' job succeeds
    type: build
    params:
      platform: ios

jobs.<job_id>.after

在运行此作业之前必须完成（成功或失败）的作业 ID 列表。

🌐 A list of job IDs that must complete (successfully or not) before this job will run.

jobs:
  build:
    type: build
    params:
      platform: ios
  notify:
    after: [build] # This job will run after build completes (whether build succeeds or fails)

jobs.<job_id>.if

if 条件决定作业是否应运行。当满足 if 条件时，作业将运行。当条件不满足时，作业将被跳过。被跳过的作业不会成功完成，并且任何在其 needs 列表中包含此作业的下游作业都不会运行。

🌐 The if conditional determines if a job should run. When an if condition is met, the job will run. When the condition is not met, the job will be skipped. A skipped job won't have completed successfully and any downstream jobs will not run that have this job in their needs list.

jobs:
  my_job:
    if: ${{ github.ref_name == 'main' }}

插值

🌐 Interpolation

你可以根据工作流运行的上下文，自定义工作流的行为——要执行的命令、控制流、环境变量、构建配置、应用版本等。

🌐 You can customize the behavior of a workflow — commands to execute, control flow, environment variables, build profile, app version, and more — based on the workflow run's context.

使用 ${{ expression }} 语法来访问上下文属性和函数。例如：${{ github.ref_name }} 或 ${{ needs.build_ios.outputs.build_id }}。

🌐 Use the ${{ expression }} syntax to access context properties and functions. For example: ${{ github.ref_name }} or ${{ needs.build_ios.outputs.build_id }}.

上下文属性

🌐 Context properties

在插值上下文中可用以下属性：

🌐 The following properties are available in interpolation contexts:

after

当前作业的 after 列表中指定的所有上游作业的记录。每个作业提供：

🌐 A record of all upstream jobs specified in the current job's after list. Each job provides:

{
  "status": "success" | "failure" | "skipped",
  "outputs": {}
}

示例：

🌐 Example:

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

needs

当前作业的 needs 列表中指定的所有上游作业的记录。每个作业提供：

🌐 A record of all upstream jobs specified in the current job's needs list. Each job provides:

{
  "status": "success" | "failure" | "skipped",
  "outputs": {}
}

大多数预封装的作业会显示特定的输出。你可以在自定义作业中使用 set-output 函数设置输出。

🌐 Most pre-packaged jobs expose specific outputs. You can set outputs in custom jobs using the set-output function.

示例：

🌐 Example:

jobs:
  setup:
    outputs:
      date: ${{ steps.current_date.outputs.date }}
    steps:
      - id: current_date
        run: |
          DATE=$(date +"%Y.%-m.%-d")
          set-output date "$DATE"

  build_ios:
    needs: [setup]
    type: build
    env:
      # You might use process.env.VERSION_SUFFIX to customize
      # app version in your dynamic app config.
      VERSION_SUFFIX: ${{ needs.setup.outputs.date }}
    params:
      platform: ios
      profile: development

steps

当前作业中所有步骤的记录。每个步骤都使用 set-output 函数提供其输出集合。

🌐 A record of all steps in the current job. Each step provides its outputs set using the set-output function.

注意： steps 上下文仅在作业的步骤中可用，在工作流级别不可用。要将某个步骤的输出暴露给其他作业，请使用 set-output 功能和作业的 outputs 配置。

示例：

🌐 Example:

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

  another_job:
    needs: [my_job]
    steps:
      - run: echo "Value: ${{ needs.my_job.outputs.value }}"

inputs

在使用 workflow_dispatch 手动触发工作流时提供的输入记录。只有在通过带有输入参数的 eas workflow:run 命令触发工作流时才可用。

🌐 A record of inputs provided when manually triggering a workflow with workflow_dispatch. Available when the workflow is triggered via eas workflow:run command with input parameters.

示例：

🌐 Example:

on:
  workflow_dispatch:
    inputs:
      name:
        type: string
        required: true

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

github

为了简化从 GitHub Actions 到 EAS Workflows 的迁移，我们公开了一些你可能会觉得有用的上下文的字段。

🌐 To ease the migration from GitHub Actions to EAS Workflows we expose some context fields you may find useful.

type GitHubContext = {
  triggering_actor?: string;
  event_name: 'pull_request' | 'push' | 'schedule' | 'workflow_dispatch';
  sha: string;
  ref: string; // e.g. refs/heads/main
  ref_name: string; // e.g. main
  ref_type: 'branch' | 'tag' | 'other';
  commit_message?: string; // Only available for push and schedule events
  label?: string;
  repository?: string;
  repository_owner?: string;
  event?: {
    label?: {
      name: string;
    };
    // Only available for push and schedule events
    head_commit?: {
      message: string;
      id: string;
    };
    pull_request?: {
      number: number;
    };
    number?: number;
    schedule?: string;
    inputs?: Record<string, string | number | boolean>;
  };
};

如果从 eas workflow:run 启动工作流运行，其 event_name 将是 workflow_dispatch，其余所有属性将为空。

🌐 If a workflow run is started from eas workflow:run, its event_name will be workflow_dispatch and all the rest of the properties will be empty.

示例：

🌐 Example:

jobs:
  build_ios:
    type: build
    if: ${{ github.ref_name == 'main' }}
    params:
      platform: ios
      profile: production

workflow

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

🌐 Information about the current workflow.

type WorkflowContext = {
  id: string;
  name: string;
  filename: string;
  url: string;
};

示例：

🌐 Example:

jobs:
  notify_slack:
    after: [...]
    type: slack
    params:
      message: |
        Workflow run completed: ${{ workflow.name }}
        View details: ${{ workflow.url }}

env

当前作业上下文中可用的环境变量记录。

🌐 A record of environment variables available in the current job context.

注意: env 上下文仅在作业的上下文中可用，而在工作流级别不可用。

示例：

🌐 Example:

jobs:
  my_job:
    steps:
      - run: echo "API URL: ${{ env.API_URL }}"

上下文函数

🌐 Context functions

在插值上下文中可用以下函数：

🌐 The following functions are available in interpolation contexts:

success()

返回所有先前的任务是否都已成功。

🌐 Returns whether all previous jobs have succeeded.

jobs:
  notify:
    if: ${{ success() }}
    steps:
      - run: echo "All jobs succeeded"

failure()

返回是否有任何先前的任务失败。

🌐 Returns whether any previous job has failed.

jobs:
  notify:
    if: ${{ failure() }}
    steps:
      - run: echo "A job failed"

fromJSON(value)

解析一个 JSON 字符串。等同于 JSON.parse()。

🌐 Parses a JSON string. Equivalent to JSON.parse().

示例：

🌐 Example:

jobs:
  publish_update:
    type: update

  print_debug_info:
    needs: [publish_update]
    steps:
      - run: |
          echo "First update group: ${{ needs.publish_update.outputs.first_update_group_id }}"
          echo "Second update group: ${{ fromJSON(needs.publish_update.outputs.updates_json || '[]')[1].group }}"

toJSON(value)

将一个值转换为 JSON 字符串。相当于 JSON.stringify()。

🌐 Converts a value to a JSON string. Equivalent to JSON.stringify().

示例：

🌐 Example:

jobs:
  my_job:
    steps:
      - run: echo '${{ toJSON(github.event) }}'

contains(value, substring)

检查 value 是否包含 substring。

🌐 Checks whether value contains substring.

示例：

🌐 Example:

jobs:
  my_job:
    if: ${{ contains(github.ref_name, 'feature') }}
    steps:
      - run: echo "Feature branch"

startsWith(value, prefix)

检查 value 是否以 prefix 开头。

🌐 Checks whether value starts with prefix.

示例：

🌐 Example:

jobs:
  my_job:
    if: ${{ startsWith(github.ref_name, 'release') }}
    steps:
      - run: echo "Release branch"

endsWith(value, suffix)

检查 value 是否以 suffix 结尾。

🌐 Checks whether value ends with suffix.

示例：

🌐 Example:

jobs:
  my_job:
    if: ${{ endsWith(github.ref_name, '-production') }}
    steps:
      - run: echo "Production branch"

hashFiles(...globs)

返回与提供的通配符模式匹配的文件的哈希值。对缓存键很有用。

🌐 Returns a hash of files matching the provided glob patterns. Useful for cache keys.

注意: hashFiles 函数仅在作业的步骤中可用，在工作流层级不可用。

示例：

🌐 Example:

jobs:
  my_job:
    steps:
      - run: echo "Dependencies hash: ${{ hashFiles('package-lock.json', 'yarn.lock') }}"

replaceAll(input, stringToReplace, replacementString)

将 input 中的所有 stringToReplace 替换为 replacementString。

🌐 Replaces all occurrences of stringToReplace in input with replacementString.

示例：

🌐 Example:

jobs:
  my_job:
    steps:
      - run: echo "${{ replaceAll(github.ref_name, '/', '-') }}"

substring(input, start, end)

从 input 中提取从 start 开始到 end 结束的子字符串。如果未提供 end，则从 start 提取到 input 的末尾。底层使用 String#substring 实现。

🌐 Extracts a substring from input starting at start and ending at end. If end is not provided, the substring is extracted from start to the end of input. Uses String#substring under the hood.

示例：

🌐 Example:

jobs:
  my_job:
    steps:
      - run: echo "${{ substring(github.ref_name, 0, 50) }}"

预打包作业

🌐 Pre-packaged jobs

jobs.<job_id>.type

指定要运行的预打包作业类型。预打包作业会根据工作流详细信息页面上的作业类型生成专门的用户界面。

🌐 Specifies the type of pre-packaged job to run. Pre-packaged jobs produce specialized UI according to the type of job on the workflow's detail page.

jobs:
  my_job:
    type: build

了解以下不同的预打包作业。

🌐 Learn about the different pre-packaged jobs below.

build

使用 EAS Build 创建项目的 Android 或 iOS 构建。详细信息和示例请参阅 构建作业文档。

🌐 Creates an Android or iOS build of your project using EAS Build. See Build job documentation for detailed information and examples.

jobs:
  my_job:
    type: build
    params:
      platform: ios | android # required
      profile: string # optional, default: production
      message: string # optional

此作业输出以下属性：

🌐 This job outputs the following properties:

{
  "build_id": string,
  "app_build_version": string | null,
  "app_identifier": string | null,
  "app_version": string | null,
  "channel": string | null,
  "distribution": "internal" | "store" | null,
  "fingerprint_hash": string | null,
  "git_commit_hash": string | null,
  "platform": "ios" | "android" | null,
  "profile": string | null,
  "runtime_version": string | null,
  "sdk_version": string | null,
  "simulator": "true" | "false" | null
}

deploy

使用 EAS Hosting 部署你的应用。有关详细信息和示例，请参阅 部署作业文档。

🌐 Deploys your application using EAS Hosting. See Deploy job documentation for detailed information and examples.

jobs:
  my_job:
    type: deploy
    params:
      alias: string # optional
      prod: boolean # optional

此作业输出以下属性：

🌐 This job outputs the following properties:

{
  "deploy_json": string, // JSON object containing the deployment details (output of `npx eas-cli deploy --json`).
  "deploy_url": string, // URL to the deployment. It uses production URL if this was a production deployment. Otherwise, it uses the first alias URL or the deployment URL.
  "deploy_alias_url": string, // Alias URL to the deployment (for example, `https://account-project--alias.expo.app`).
  "deploy_deployment_url": string, // Unique URL to the deployment (for example, `https://account-project--uniqueid.expo.app`).
  "deploy_identifier": string, // Identifier of the deployment.
  "deploy_dashboard_url": string, // URL to the deployment dashboard (for example, `https://expo.dev/projects/[project]/hosting/deployments`).
}

fingerprint

计算你项目的指纹。有关详细信息和示例，请参阅指纹作业文档。

🌐 Calculates a fingerprint of your project. See Fingerprint job documentation for detailed information and examples.

jobs:
  my_job:
    type: fingerprint
    environment: production # Should match your build profile

此作业输出以下属性：

🌐 This job outputs the following properties:

{
  "android_fingerprint_hash": string,
  "ios_fingerprint_hash": string,
}

注意： 为了准确匹配指纹，请确保指纹任务的 environment 与你的构建配置相符。建议使用 EAS 环境变量 而不是 env，以在各任务间获得更一致的结果。

get-build

从 EAS 检索与提供的参数匹配的现有构建。有关详细信息和示例，请参阅 获取构建作业文档。

🌐 Retrieves an existing build from EAS that matches the provided parameters. See Get Build job documentation for detailed information and examples.

jobs:
  my_job:
    type: get-build
    params:
      platform: ios | android # optional
      profile: string # optional
      distribution: store | internal | simulator # optional
      channel: string # optional
      app_identifier: string # optional
      app_build_version: string # optional
      app_version: string # optional
      git_commit_hash: string # optional
      fingerprint_hash: string # optional
      sdk_version: string # optional
      runtime_version: string # optional
      simulator: boolean # optional
      wait_for_in_progress: boolean # optional

此作业输出以下属性：

🌐 This job outputs the following properties:

{
  "build_id": string,
  "app_build_version": string | null,
  "app_identifier": string | null,
  "app_version": string | null,
  "channel": string | null,
  "distribution": "internal" | "store" | null,
  "fingerprint_hash": string | null,
  "git_commit_hash": string | null,
  "platform": "ios" | "android" | null,
  "profile": string | null,
  "runtime_version": string | null,
  "sdk_version": string | null,
  "simulator": "true" | "false" | null
}

submit

使用 EAS Submit 将 Android 或 iOS 构建提交到应用商店。有关详细信息和示例，请参见 提交作业文档。

🌐 Submits an Android or iOS build to the app store using EAS Submit. See Submit job documentation for detailed information and examples.

jobs:
  my_job:
    type: submit
    params:
      build_id: string # required
      profile: string # optional, default: production
      groups: string[] # optional

此作业输出以下属性：

🌐 This job outputs the following properties:

{
  "apple_app_id": string | null, // Apple App ID. https://expo.fyi/asc-app-id
  "ios_bundle_identifier": string | null, // iOS bundle identifier of the submitted build. https://expo.fyi/bundle-identifier
  "android_package_id": string | null // Submitted Android package ID. https://expo.fyi/android-package
}

testflight

将 iOS 构建分发到 TestFlight 的内部和外部测试组。有关详细信息和示例，请参阅 TestFlight 作业文档。

🌐 Distributes iOS builds to TestFlight internal and external testing groups. See TestFlight job documentation for detailed information and examples.

jobs:
  my_job:
    type: testflight
    params:
      build_id: string # required
      profile: string # optional, default: production
      internal_groups: string[] # optional
      external_groups: string[] # optional
      changelog: string # optional
      submit_beta_review: boolean # optional
      wait_processing_timeout_seconds: number # optional, default: 1800 (30 minutes)

此作业输出以下属性：

🌐 This job outputs the following properties:

{
  "apple_app_id": string | null, // Apple App ID. https://expo.fyi/asc-app-id
  "ios_bundle_identifier": string | null // iOS bundle identifier of the submitted build. https://expo.fyi/bundle-identifier
}

update

使用 EAS 更新 发布更新。有关详细信息和示例，请参阅 更新作业文档。

🌐 Publishes an update using EAS Update. See Update job documentation for detailed information and examples.

jobs:
  my_job:
    type: update
    params:
      message: string # optional
      platform: string # optional - android | ios | all, defaults to all
      branch: string # optional
      channel: string # optional - cannot be used with branch
      private_key_path: string # optional
      upload_sentry_sourcemaps: boolean # optional - defaults to "try uploading, but don't fail the job if it fails"

此作业输出以下属性：

🌐 This job outputs the following properties:

{
  "first_update_group_id": string, // ID of the first update group. You can use it to e.g. construct the update URL for a development client deep link.
  "updates_json": string // Stringified JSON array of update groups. Output of `eas update --json`.
}

maestro

在构建上运行 Maestro 测试。有关详细信息和示例，请参阅 Maestro 作业文档。

🌐 Runs Maestro tests on a build. See Maestro job documentation for detailed information and examples.

重要 Maestro 测试处于 alpha 阶段。

jobs:
  my_job:
    type: maestro
    environment: production | preview | development # optional, defaults to preview
    image: string # optional. See https://expo.nodejs.cn/eas/workflows/syntax/#jobsjob_idruns_on  for a list of available images.
    params:
      build_id: string # required
      flow_path: string | string[] # required
      shards: number # optional, defaults to 1
      retries: number # optional, defaults to 1
      record_screen: boolean # optional, defaults to false. If true, uploads a screen recording of the tests.
      include_tags: string | string[] # optional. Tags to include in the tests. Will be passed to Maestro as `--include-tags`.
      exclude_tags: string | string[] # optional. Tags to exclude from the tests. Will be passed to Maestro as `--exclude-tags`.
      maestro_version: string # optional. Version of Maestro to use for the tests. If not provided, the latest version will be used.
      android_system_image_package: string # optional. Android emulator system image package to use.
      device_identifier: string | { android?: string, ios?: string } # optional. Device identifier to use for the tests.
      output_format?: string # optional. Maestro test report format. Will be passed to Maestro as `--format`. Can be `junit` or other supported formats.

maestro-cloud

在 Maestro Cloud 上对构建运行 Maestro 测试。有关详细信息和示例，请参阅 Maestro Cloud 作业文档。

🌐 Runs Maestro tests on a build in Maestro Cloud. See Maestro Cloud job documentation for detailed information and examples.

重要 在 Maestro Cloud 中运行测试需要拥有 Maestro Cloud 账户和云计划订阅。请访问 Maestro 文档 了解更多信息。

jobs:
  my_job:
    type: maestro-cloud
    environment: production | preview | development # optional, defaults to preview
    image: string # optional. See https://expo.nodejs.cn/eas/workflows/syntax/#jobsjob_idruns_on  for a list of available images.
    params:
      build_id: string # required. ID of the build to test.
      maestro_project_id: string # required. Maestro Cloud project ID. Example: `proj_01jw6hxgmdffrbye9fqn0pyzm0`.
      flows: string # required. Path to the Maestro flow file or directory containing the flows to run. Corresponds to `--flows` param to `maestro cloud`.
      maestro_api_key: string # optional. The API key to use for the Maestro project. By default, `MAESTRO_CLOUD_API_KEY` environment variable will be used. Corresponds to `--api-key` param to `maestro cloud`.
      include_tags: string | string[] # optional. Tags to include in the tests. Will be passed to Maestro as `--include-tags`.
      exclude_tags: string | string[] # optional. Tags to exclude from the tests. Will be passed to Maestro as `--exclude-tags`.
      maestro_version: string # optional. Version of Maestro to use for the tests. If not provided, the latest version will be used.
      android_api_level: string # optional. Android API level to use for the tests. Will be passed to Maestro as `--android-api-level`.
      maestro_config: string # optional. Path to the Maestro `config.yaml` file to use for the tests. Will be passed to Maestro as `--config`.
      device_locale: string # optional. Device locale to use for the tests. Will be passed to Maestro as `--device-locale`. Run `maestro cloud --help` for a list of supported values.
      device_model: string # optional. Model of the device to use for the tests. Will be passed to Maestro as `--device-model`. Run `maestro cloud --help` for a list of supported values.
      device_os: string # optional. OS of the device to use for the tests. Will be passed to Maestro as `--device-os`. Run `maestro cloud --help` for a list of supported values.
      name: string # optional. Name for the Maestro Cloud upload. Corresponds to `--name` param to `maestro cloud`.
      branch: string # optional. Override for the branch the Maestro Cloud upload originated from. By default, if the workflow run has been triggered from GitHub, the branch of the workflow run will be used. Corresponds to `--branch` param to `maestro cloud`.
      async: boolean # optional. Run the Maestro Cloud tests asynchronously. If true, the status of the job will only denote whether the upload was successful, *not* whether the tests succeeded. Corresponds to `--async` param to `maestro cloud`.

slack

使用 webhook URL 向 Slack 通道发送消息。有关详细信息和示例，请参阅 Slack 任务文档。

🌐 Sends a message to a Slack channel using a webhook URL. See Slack job documentation for detailed information and examples.

jobs:
  my_job:
    type: slack
    params:
      webhook_url: string # required
      message: string # required if payload is not provided
      payload: object # required if message is not provided

github-comment

自动将工作流已完成的构建、更新和部署的综合报告发布到 GitHub 拉取请求或你提供的内容中。有关详细信息和示例，请参阅 GitHub 评论作业文档。

🌐 Automatically posts comprehensive reports of your workflow's completed builds, updates, and deployments to GitHub pull requests or content provided by you. See GitHub Comment job documentation for detailed information and examples.

jobs:
  my_job:
    type: github-comment
    params:
      message: string # optional - custom message to include in the report
      build_ids: string[] # optional - specific build IDs to include, defaults to all related to the running workflow
      update_group_ids: string[] # optional - specific update group IDs to include, defaults to all related to the workflow
      deployment_ids: string[] # optional - specific deployment IDs to include, defaults to all related to the workflow

  # instead of using message and the builds, updates, and deployments table, you can also override the comment contents with `payload`
  custom_github_comment:
    type: github-comment
    params:
      payload: string # optional - raw markdown/HTML content for fully custom comment

此作业输出以下属性：

🌐 This job outputs the following properties:

{
  "comment_url": string | undefined  // URL of the posted GitHub comment
}

require-approval

在继续工作流程之前，需要用户批准。用户可以批准或拒绝，这将转化为作业的成功或失败。有关详细信息和示例，请参阅需要批准的作业文档。

🌐 Requires approval from a user before continuing with the workflow. A user can approve or reject which translates to success or failure of the job. See Require Approval job documentation for detailed information and examples.

jobs:
  confirm:
    type: require-approval

doc

在工作流日志中显示一个 Markdown 部分。有关详细信息和示例，请参见Doc 作业文档。

🌐 Displays a Markdown section in the workflow logs. See Doc job documentation for detailed information and examples.

jobs:
  next_steps:
    type: doc
    params:
      md: string

repack

从现有构建重新打包应用。此任务重新打包应用的元数据和 JavaScript 包，而无需进行完整的原生重建，这对于创建与特定指纹兼容的更快速构建非常有用。有关详细信息和示例，请参阅 Repack job documentation。

🌐 Repackages an app from an existing build. This job repackages the app's metadata and JavaScript bundle without performing a full native rebuild, which is useful for creating a faster build compatible with a specific fingerprint. See Repack job documentation for detailed information and examples.

jobs:
  next_steps:
    type: repack
    params:
      build_id: string # required
      profile: string # optional
      embed_bundle_assets: boolean # optional
      message: string # optional
      repack_version: string # optional

自定义作业

🌐 Custom jobs

运行自定义代码并可以使用内置的 EAS 函数。不需要 type 字段。

🌐 Runs custom code and can use built-in EAS functions. Does not require a type field.

jobs:
  my_job:
    steps:
      # ...

jobs.<job_id>.steps

一个作业包含一系列称为 steps 的任务。步骤可以运行命令。steps 只能在自定义作业和 build 作业中提供。

🌐 A job contains a sequence of tasks called steps. Steps can run commands. steps may only be provided in custom jobs and build jobs.

jobs:
  my_job:
    steps:
      - name: My first step
        run: echo "Hello World"

jobs.<job_id>.outputs

由作业定义的输出列表。这些输出对于依赖此作业的所有下游作业都是可访问的。要设置输出，请在作业步骤中使用 set-output 函数。

🌐 A list of outputs defined by the job. These outputs are accessible to all downstream jobs that depend on this job. To set outputs, use the set-output function within a job step.

下游作业可以在插值上下文中使用以下表达式来访问这些输出：

🌐 Downstream jobs can access these outputs using the following expressions within interpolation contexts:

• needs.<job_id>.outputs.<output_name>
• after.<job_id>.outputs.<output_name>

这里，<job_id> 指的是上游作业的标识符，而 <output_name> 指的是你想要访问的具体输出变量。

🌐 Here, <job_id> refers to the identifier of the upstream job, and <output_name> refers to the specific output variable you want to access.

在下面的示例中，set-output 函数将名为 test 的输出设置为 job_1 的 step_1 步骤中的值 hello world。稍后在 job_2 中，它通过 needs.job_1.outputs.output_1 在 step_2 中被访问。

🌐 In the example below, the set-output function sets the output named test to the value hello world in job_1's step_1 step. Later in job_2, it's accessed in step_2 using needs.job_1.outputs.output_1.

jobs:
  job_1:
    outputs:
      output_1: ${{ steps.step_1.outputs.test }}
    steps:
      - id: step_1
        run: set-output test "hello world"
  job_2:
    needs: [job_1]
    steps:
      - id: step_2
        run: echo ${{ needs.job_1.outputs.output_1 }}

jobs.<job_id>.image

指定用于该作业的虚拟机镜像。可用镜像请参见 基础设施。

🌐 Specifies the VM image to use for the job. See Infrastructure for available images.

jobs:
  my_job:
    image: auto | string # optional, defaults to 'auto'

jobs.<job_id>.runs_on

指定将执行该作业的工作者。仅在自定义作业中可用。

🌐 Specifies the worker that will execute the job. Available only on custom jobs.

jobs:
  my_job:
    runs_on: linux-medium | linux-large |
      linux-medium-nested-virtualization |
      linux-large-nested-virtualization |
      macos-medium | macos-large # optional, defaults to linux-medium

注意： 对于 Android 模拟器任务，你必须使用 linux-*-nested-virtualization 工作节点。对于 iOS 构建和 iOS 模拟器任务，你必须使用 macos-* 工作节点。

jobs.<job_id>.steps.<step>.id

id 属性用于引用作业中的步骤。用于在下游作业中使用该步骤的输出。

🌐 The id property is used to reference the step in the job. Useful for using the step's output in a downstream job.

jobs:
  my_job:
    outputs:
      test: ${{ steps.step_1.outputs.test }} # References the output from step_1
    steps:
      - id: step_1
        run: set-output test "hello world"

jobs.<job_id>.steps.<step>.name

步骤的人性化名称，会显示在作业的日志中。当未提供步骤名称时，run 命令将用作步骤名称。

🌐 The human-friendly name of the step, which is displayed in the job's logs. When a step's name is not provided, the run command is used as the step name.

jobs:
  my_job:
    steps:
      - name: My first step
        run: echo "Hello World"

jobs.<job_id>.steps.<step>.run

在步骤中运行的 shell 命令。

🌐 The shell command to run in the step.

jobs:
  my_job:
    steps:
      - run: echo "Hello World"

jobs.<job_id>.steps.<step>.shell

用于运行命令的 shell。默认为 bash。

🌐 The shell to use for running the command. Defaults to bash.

jobs:
  my_job:
    steps:
      - run: echo "Hello World"
        shell: bash

jobs.<job_id>.steps.<step>.working_directory

运行命令的目录。如果在步骤级别定义，它将覆盖作业中已定义的 jobs.<job_id>.defaults.run.working_directory 设置。

jobs:
  my_job:
    steps:
      - uses: eas/checkout
      - run: pwd # prints: /home/expo/workingdir/build/my-app
        working_directory: ./my-app

jobs.<job_id>.steps.<step>.uses

EAS 提供了一组内置的可重用函数，你可以在工作流步骤中使用。uses 关键字用于指定要使用的函数。所有内置函数都以 eas/ 前缀开头。

🌐 EAS provides a set of built-in reusable functions that you can use in workflow steps. The uses keyword is used to specify the function to use. All built-in functions start with the eas/ prefix.

jobs:
  my_job:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - uses: eas/prebuild
      - name: List files
        run: ls -la

以下是你可以在工作流步骤中使用的内置函数列表。

🌐 Below is a list of built-in functions you can use in your workflow steps.

eas/checkout

签出你的项目源文件。

🌐 Checks out your project source files.

jobs:
  my_job:
    steps:
      - uses: eas/checkout

eas/install_node_modules

根据你的项目检测到的包管理器（bun、npm、pnpm 或 Yarn）安装 node_modules。适用于多仓库项目。

🌐 Installs node_modules using the package manager (bun, npm, pnpm, or Yarn) detected based on your project. Works with monorepos.

jobs:
  my_job:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules

eas/download_build

下载指定构建的应用归档文件。默认情况下，下载的构件可以是 .apk、.aab、.ipa 或 .app 文件，或者包含一个或多个这些文件的 .tar.gz 归档文件。如果构件是 .tar.gz 归档文件，它将被解压，并返回第一个匹配指定扩展名的文件。如果构建未生成任何应用归档文件，该步骤将失败。

🌐 Downloads application archive of a given build. By default, the downloaded artifact can be an .apk, .aab, .ipa, or .app file, or a .tar.gz archive containing one or more of these files. If the artifact is a .tar.gz archive, it will be extracted and the first file matching the specified extensions will be returned. If the build produced no application archive, the step will fail.

jobs:
  my_job:
    steps:
      - uses: eas/download_build
        with:
          build_id: string # Required. ID of the build to download.
          extensions: [apk, aab, ipa, app] # Optional. List of file extensions to look for. Defaults to ["apk", "aab", "ipa", "app"].

输出:

• artifact_path：匹配应用存档的绝对路径。此输出可以作为工作流中其他步骤的输入。例如，可用于进一步上传或处理该工件。

用法示例：

🌐 Example usage:

jobs:
  build_ios:
    type: build
    params:
      platform: ios
      profile: production

  my_job:
    needs: [build_ios]
    steps:
      - uses: eas/download_build
        id: download_build
        with:
          build_id: ${{ needs.build_ios.outputs.build_id }}
      - name: Print artifact path
        run: |
          echo "Artifact path: ${{ steps.download_build.outputs.artifact_path }}"

eas/prebuild

使用包管理器（bun、npm、pnpm 或 Yarn）运行 expo prebuild 命令，根据你的项目自动检测适合的命令，以匹配你的构建类型和构建环境。

🌐 Runs the expo prebuild command using the package manager (bun, npm, pnpm, or Yarn) detected based on your project with the command best suited for your build type and build environment.

jobs:
  my_job:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - uses: eas/prebuild

jobs:
  my_job:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - uses: eas/resolve_apple_team_id_from_credentials
        id: resolve_apple_team_id_from_credentials
      - uses: eas/prebuild
        with:
          clean: false
          apple_team_id: ${{ steps.resolve_apple_team_id_from_credentials.outputs.apple_team_id }}

eas/restore_cache

从指定的键恢复先前保存的缓存。这对于通过重用已缓存的工件（如已编译的依赖、构建工具或其他中间构建输出）来加快构建速度非常有用。

🌐 Restores a previously saved cache from a specified key. This is useful for speeding up builds by reusing cached artifacts like compiled dependencies, build tools, or other intermediate build outputs.

jobs:
  my_job:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - uses: eas/prebuild
      - uses: eas/restore_cache
        with:
          key: cache-${{ hashFiles('package-lock.json') }}
          restore_keys: cache
          path: /path/to/cache

jobs:
  my_job:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - uses: eas/prebuild
      - uses: eas/restore_cache
        with:
          key: cache-${{ hashFiles('package-lock.json') }}
          path: /path/to/cache

eas/save_cache

将缓存保存到指定的键。这允许你持久化构建产物、已编译的依赖或其他中间输出，这些内容可以在后续构建中重用，从而加快构建过程。

🌐 Saves a cache to a specified key. This allows you to persist build artifacts, compiled dependencies, or other intermediate outputs that can be reused in subsequent builds to speed up the build process.

jobs:
  my_job:
    steps:
      - uses: eas/checkout
      - uses: eas/install_node_modules
      - uses: eas/prebuild
      - uses: eas/restore_cache
        with:
          key: cache-${{ hashFiles('package-lock.json') }}
          path: /path/to/cache
      - name: Build Android app
        run: cd android && ./gradlew assembleRelease
      - uses: eas/save_cache
        with:
          key: cache-${{ hashFiles('package-lock.json') }}
          path: /path/to/cache

eas/send_slack_message

将指定消息发送到配置好的 Slack webhook URL，然后在相关的 Slack 通道中发布。消息可以以纯文本形式或 Slack Block Kit 消息形式指定。

🌐 Sends a specified message to a configured Slack webhook URL, which then posts it in the related Slack channel. The message can be specified as plaintext or as a Slack Block Kit message.

在这两种情况下，你都可以在消息中引用构建作业属性并使用其他步骤的输出进行动态评估。例如，Build URL: https://expo.dev/builds/${{ needs.build_ios.outputs.build_id }}、Build finished with status: ${{ after.build_android.status }}。

🌐 With both cases, you can reference build job properties and use other steps outputs in the message for dynamic evaluation. For example, Build URL: https://expo.dev/builds/${{ needs.build_ios.outputs.build_id }}, Build finished with status: ${{ after.build_android.status }}.

必须指定 message 或 payload 中的一个，但不能同时指定两者。

🌐 Either message or payload has to be specified, but not both.

jobs:
  my_job:
    steps:
      - uses: eas/send_slack_message
        with:
          message: 'This is a message to plain input URL'
          slack_hook_url: 'https://hooks.slack.com/services/[rest_of_hook_url]'

eas/use_npm_token

配置 Node 包管理器（bun、npm、pnpm 或 Yarn）以用于私有包，发布到 npm 或私有注册表。

🌐 Configures Node package managers (bun, npm, pnpm, or Yarn) for use with private packages, published either to npm or a private registry.

在你的项目密钥中设置 NPM_TOKEN，此功能将通过创建带有令牌的 .npmrc 来配置构建环境。

🌐 Set NPM_TOKEN in your project's secrets, and this function will configure the build environment by creating .npmrc with the token.

jobs:
  my_job:
    name: Install private npm modules
    steps:
      - uses: eas/checkout
      - uses: eas/use_npm_token
      - name: Install dependencies
        run: npm install # <---- Can now install private packages

eas/download_artifact

根据工件的ID或名称从EAS下载工件。用于将以前作业的工件发送到其他服务。

🌐 Downloads an artifact from EAS given an artifact's ID or name. Useful for sending artifacts from previous jobs to other services.

jobs:
  my_job:
    steps:
      - uses: eas/download_artifact
        with:
          name: string # Required if artifact_id is not provided. Name of the artifact to download.
          artifact_id: string # Required if artifact_name is not provided. ID of the artifact to download.

属性

🌐 Properties

输出

🌐 Outputs

示例

🌐 Example

jobs:
  maestro_tests:
    type: maestro
    params:
      build_id: '123-abc'
      flow_path: 'path/to/flow.yaml'
      output_format: 'junit'
  my_job:
    needs: [maestro_tests]
    steps:
      - uses: eas/download_artifact
        id: download_artifact
        with:
          name: 'iOS Maestro Test Report (junit)'
      - name: Print Maestro output
        run: echo ${{ steps.download_artifact.outputs.artifact_path }}

内置 shell 函数

🌐 Built-in shell functions

EAS Workflows 提供了以下 shell 函数，你可以在工作流步骤中使用它来设置变量输出。

🌐 EAS Workflows provides the following shell function that you can use in your workflow steps to set variable outputs.

set-output

设置一个输出变量，该变量可被工作流中的其他步骤或其他作业访问。

🌐 Sets an output variable that can be accessed by other steps or other jobs in the workflow.

set-output <name> <value>

与另一个步骤共享变量的示例用法：

🌐 Example usage for sharing a variable with another step:

jobs:
  my_job:
    steps:
      - id: step_1
        run: set-output variable_1 "Variable 1"
      - id: step_2
        run: echo ${{ steps.step_1.outputs.variable_1 }} # prints: Variable 1

与另一个作​​业共享变量的示例用法：

🌐 Example usage for sharing a variable with another job:

jobs:
  job_1:
    outputs:
      variable_1: ${{ steps.step_1.outputs.variable_1 }}
    steps:
      - id: step_1
        run: set-output variable_1 "Variable 1"
  job_2:
    needs: [job_1]
    steps:
      - run: echo ${{ needs.job_1.outputs.variable_1 }} # prints: Variable 1

set-env

设置一个环境变量，该变量可用于同一作业中的后续步骤。使用 export 在某一步的命令中导出的环境变量不会自动对其他步骤可见。要与其他步骤共享环境变量，请使用 set-env 可执行文件。

🌐 Sets an environment variable that is available to subsequent steps within the same job. Environment variables exported using export in one step's command are not automatically exposed to other steps. To share an environment variable with other steps, use the set-env executable.

set-env <name> <value>

set-env 期望被调用时带有两个参数：环境变量的名称和值。例如，set-env NPM_TOKEN "abcdef" 会将 $NPM_TOKEN 变量及其值 abcdef 暴露给后续步骤。

注意： 与 set-env 共享的变量不会自动在本地导出。如果你想在当前步骤中使用该变量，需要自己调用 export。

将环境变量与另一个步骤共享的示例用法：

🌐 Example usage for sharing an environment variable with another step:

jobs:
  my_job:
    steps:
      - name: Set environment variables
        run: |
          # Using export only makes it available in the current step
          export LOCAL_VAR="only in this step"

          # Using set-env makes it available in subsequent steps
          set-env SHARED_VAR "available in next steps"

          # SHARED_VAR is not yet available in current step's environment
          echo "LOCAL_VAR: $LOCAL_VAR"     # prints: only in this step
          echo "SHARED_VAR: $SHARED_VAR"   # prints: (empty)
      - name: Use shared variable
        run: |
          # SHARED_VAR is now available
          # @info #
          echo "SHARED_VAR: $SHARED_VAR"   # prints: available in next steps
          # @end #

在作业之间共享环境变量

🌐 Sharing environment variables between jobs

set-env 函数只会与 同一作业 内的其他步骤共享环境变量。要在不同作业之间共享值，请使用作业的 outputs 配合 set-output，并通过接收作业上的 env 属性传递它们：

🌐 The set-env function only shares environment variables with other steps within the same job. To share values between different jobs, use the job's outputs with set-output and pass them via the env property on the receiving job:

jobs:
  job_1:
    outputs:
      my_value: ${{ steps.step_1.outputs.my_value }}
    steps:
      - id: step_1
        run: set-output my_value "value from job_1"

  job_2:
    needs: [job_1]
    env:
      MY_VALUE: ${{ needs.job_1.outputs.my_value }}
    steps:
      - run: echo "MY_VALUE: $MY_VALUE"  # prints: value from job_1