This documentation is available as Markdown for AI agents and LLMs. See the full Markdown index or append .md to any documentation URL.
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，且文件大小必须为 16 KiB 或更小。如果你是 YAML 新手，想了解更多，可以查看 在几分钟内学会 YAML。
🌐 Workflow files use YAML syntax, must have either a .yml or .yaml file extension, and must be 16 KiB or smaller. 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:
my-app.easworkflowscreate-development-builds.ymlpublish-preview-update.ymldeploy-to-production.ymleas.json配置参考
🌐 Configuration reference
以下是工作流配置文件语法的参考。
🌐 Below is a reference for the syntax of the workflow configuration file.
name
工作流的人性化名称。它会显示在 EAS 仪表板的工作流列表页面，并且是工作流详细页面的标题。如果要为每次运行设置标题，请使用 run_name。
🌐 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. To set a title for each individual run, use run_name.
name: My workflow
run_name
单个工作流程运行的标题。这与标签化工作流程本身的 name 是分开的。
🌐 The title of an individual workflow run. This is separate from name, which labels the workflow itself.
name: Deploy run_name: Deploy ${{ inputs.environment }} on: workflow_dispatch: inputs: environment: type: choice options: - preview - production required: true
该值是一个字符串。它可以包含${{ }}表达式。EAS在创建运行时渲染模板，在任何作业开始之前。
🌐 The value is a string. It can include ${{ }} expressions. EAS renders the template when it creates the run, before any job starts.
该表达式可以使用 github、app_store_connect、inputs、workflow、app 和 account 上下文。它支持所有 上下文函数，除了 success()、failure() 和 hashFiles()。这些函数需要一个已经运行过的作业或步骤。
🌐 The expression can use the github, app_store_connect, inputs, workflow, app, and account contexts. It supports all context functions except success(), failure(), and hashFiles(). Those functions need a job or step that has already run.
工作级别的上下文，比如 needs、steps 和 env 不可用。如果模板引用了不支持的上下文，执行就会失败。EAS 会记录一个错误，但不会保存自定义标题。
🌐 Job-level contexts such as needs, steps, and env are not available. If the template references an unsupported context, the run fails. EAS stores an error and does not store a custom title.
如果渲染后的文本超过255个字符，EAS会将其截断为254个字符，并添加一个省略号。
🌐 If the rendered text is longer than 255 characters, EAS truncates it to 254 characters and appends an ellipsis.
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-*
信息 你可以通过在提交信息中包含
[eas skip]、[skip eas]或[no eas]来跳过由push和pull_request触发的工作流运行。
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 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 triggers 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 trigger the workflow. Supports globs. By default, changes to any path 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 triggers on push events to all branches and does not trigger on tag pushes. If only one of the two lists is provided the other defaults to [].
使用 if: 条件，你可以决定工作流是否开始运行。
🌐 With the if: condition, you can decide whether a workflow run starts.
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.ref_delete
当 GitHub 分支或标签被删除时运行你的工作流。需要在你的 EAS 项目上有一个关联的 GitHub 仓库。
🌐 Runs your workflow when a GitHub branch or tag is deleted. Requires a linked GitHub repository on your EAS project.
使用 branches 列表，你可以仅在删除指定分支时触发工作流。例如，如果你使用 branches: ['feat/**']，只有删除与 feat/** 匹配的分支才会触发工作流。支持通配符。通过使用 ! 前缀，你可以指定要忽略的分支（你仍然需要至少提供一个不带该前缀的分支模式）。有关通配符和否定模式匹配的详细信息，请参见 on.push。
🌐 With the branches list, you can trigger the workflow only when those specified branches are deleted. For example, if you use branches: ['feat/**'], only deletion of branches matching feat/** triggers 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). See on.push for details on glob and negation pattern matching.
使用 tags 列表，你可以仅在删除那些指定标签时触发工作流。支持通配符和 ! 否定，规则与分支相同。
🌐 With the tags list, you can trigger the workflow only when those specified tags are deleted. Supports globs and ! negation with the same rules as branches.
当既没有提供 branches 也没有提供 tags 时，branches 默认为 ['*']，tags 默认为 []，这意味着工作流在任何分支被删除时触发，而在标签删除时不触发。如果只提供了两个列表中的一个，另一个则默认为 []。
🌐 When neither branches nor tags are provided, branches defaults to ['*'] and tags defaults to [], which means the workflow triggers when any branch is deleted and does not trigger on tag deletions. If only one of the two lists is provided the other defaults to [].
使用 if: 条件，你可以决定工作流是否开始运行。
🌐 With the if: condition, you can decide whether a workflow run starts.
信息 工作流文件是在删除时从默认分支 HEAD 读取的，而不是从已删除的引用读取的。
将此触发器与 branch-delete 作业配对，以在删除 GitHub 分支时移除 EAS 更新分支。请参阅 清理更新分支示例 以获取完整工作流。
🌐 Pair this trigger with the branch-delete job to remove EAS Update branches when GitHub branches are deleted. See the Clean up update branches example for a complete workflow.
on: ref_delete: branches: - feat/** - !main # other branch names and globs tags: - v* - !v2-preview** # other tag names and globs
on.pull_request
当你创建或更新针对匹配分支之一的拉取请求时，运行你的工作流。
🌐 Runs your workflow when you create or update a pull request that targets one of the matching branches.
信息 从关联仓库的一个分支库打开的拉取请求不会触发
pull_request工作流运行。
使用 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 trigger the workflow. Supports globs. Defaults to ['*'] when not provided, which means the workflow triggers 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) triggers the workflow. Defaults to ['opened', 'reopened', 'synchronize'] when not provided. Supported event types:
openededitedbase_ref_changedready_for_reviewreopenedsynchronizelabeled
edited 类型遵循 GitHub 的 pull_request.edited 行为，并在拉取请求的标题、正文或基础分支更改时触发。要仅在拉取请求的基础分支更改时触发，请使用 base_ref_changed。
🌐 The edited type follows GitHub's pull_request.edited behavior and triggers when the pull request title, body, or base branch changes. To trigger only when the pull request's base branch changes, use base_ref_changed.
branches 过滤器匹配拉取请求当前的基础分支，因此将拉取请求重新定位到匹配的分支可以触发工作流。
🌐 The branches filter matches the pull request's current base branch, so retargeting a pull request to a matching branch can trigger a workflow.
使用 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 trigger the workflow. Supports globs. By default, changes to any path trigger the workflow.
你可以添加一个if: 条件来决定工作流是否开始执行。
🌐 You can add an if: condition to decide whether a workflow run starts.
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, trigger the workflow. For example, if you use labels: ['Test'], only labeling a pull request with the Test label triggers the workflow. Defaults to [] when not provided, which means no labels trigger the workflow.
要决定工作流运行是否启动，添加一个 if: 条件。
🌐 To decide whether a workflow run starts, add an if: condition.
你也可以直接向 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.pull_request_comment
当有人在拉取请求上创建、编辑或删除评论时，运行你的工作流程。
🌐 Runs your workflow when someone creates, edits, or deletes a comment on a pull request.
信息 只有未合并的开启的拉取请求会触发
pull_request_comment工作流程运行。从已连接仓库的 fork 提交的拉取请求不会触发工作流程运行。
通过 types 列表，你可以指定哪些事件会触发工作流。如果未提供，默认为 ['created']。支持的事件类型有：
🌐 With the types list, you can specify which events trigger the workflow. Defaults to ['created'] when not provided. Supported event types:
createdediteddeleted
与on.pull_request不同，这个触发器没有branches或paths过滤器。
🌐 Unlike on.pull_request, this trigger has no branches or paths filter.
使用 if: 条件，你可以决定工作流是否开始运行。
🌐 With the if: condition, you can decide whether a workflow run starts.
on: pull_request_comment: types: - created - edited # other event types
on.app_store_connect
当选定的 App Store Connect 事件之一发生时，运行你的工作流程。
🌐 Runs your workflow when one of the selected App Store Connect events occurs.
信息 要使用此触发器，请在 EAS 仪表板 中配置你的 App Store Connect 连接。有关设置步骤，请参阅 App Store Connect 触发器设置 部分。
当存在 on.app_store_connect 时，你必须至少指定一个事件域（app_version、build_upload、external_beta 或 beta_feedback）。在已配置的事件域中，你可以指定哪些状态应触发你的工作流。
🌐 When on.app_store_connect is present, you must specify at least one event domain (app_version, build_upload, external_beta, or beta_feedback). Within a configured event domain, you can specify which states should trigger your workflow.
每个事件域也接受一个 if: 条件，所以你可以决定工作流是否启动。
🌐 Each event domain also accepts an if: condition, so you can decide whether a workflow run starts.
on.app_store_connect.app_version.states
筛选应用商店应用版本状态变化事件。未提供时，默认为所有支持的应用版本状态。
🌐 Filters app store app version state change events. Defaults to all supported app version states when not provided.
支持的值：
🌐 Supported values:
accepteddeveloper_rejectedin_reviewinvalid_binarymetadata_rejectedpending_apple_releasepending_developer_releaseprepare_for_submissionprocessing_for_distributionready_for_distributionready_for_reviewrejectedreplaced_with_new_versionwaiting_for_export_compliancewaiting_for_review
on.app_store_connect.build_upload.states
按状态筛选构建上传事件。如果未提供，则默认为所有支持的构建上传状态。
🌐 Filters build upload events by state. Defaults to all supported build upload states when not provided.
支持的值：
🌐 Supported values:
completefailedprocessingawaiting_upload
on.app_store_connect.external_beta.states
按状态筛选外部测试版事件。如果未提供，则默认为所有支持的外部测试版状态。
🌐 Filters external beta events by state. Defaults to all supported external beta states when not provided.
支持的值：
🌐 Supported values:
processingprocessing_exceptionmissing_export_complianceready_for_beta_testingin_beta_testingexpiredready_for_beta_submissionin_export_compliance_reviewwaiting_for_beta_reviewin_beta_reviewbeta_rejectedbeta_approved
on.app_store_connect.beta_feedback.types
按类型过滤测试人员报告的测试版反馈。如果未提供，则默认为所有支持的测试版反馈类型。
🌐 Filters beta feedback reported by testers by its type. Defaults to all supported beta feedback types when not provided.
支持的值：
🌐 Supported values:
crashscreenshot
所有筛选值必须为小写，并且区分大小写。
🌐 All filter values must be lowercase and are case-sensitive.
# Triggers when: # - the app version enters review, # - a build upload completes or fails, # - an external beta build is ready for testing or approved, # - a tester reports a crash via TestFlight. on: app_store_connect: app_version: states: - ready_for_review - waiting_for_review build_upload: states: - complete - failed external_beta: states: - ready_for_beta_testing - beta_approved beta_feedback: types: - crash
# Triggers on any app version or build upload state change. on: app_store_connect: app_version: {} build_upload: {}
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:
-
命令行标志：
Terminal -
通过标准输入传输 JSON：
Terminal -
交互式提示：如果缺少必要的输入，并且你没有使用
--non-interactive，CLI 会提示你输入这些内容：Terminal
用法
🌐 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' }}!"
on.<trigger>.if
触发器上的 if 条件决定工作流程是否开始运行。
🌐 The if condition on a trigger decides whether a workflow run starts.
你可以在 push、ref_delete、pull_request、pull_request_labeled、pull_request_comment 以及每个 app_store_connect 事件域（app_version、build_upload、external_beta 或 beta_feedback）下添加 if:。
🌐 You can add if: under push, ref_delete, pull_request, pull_request_labeled, pull_request_comment, and each app_store_connect event domain (app_version, build_upload, external_beta, or beta_feedback).
这个值是布尔值或一个表达式字符串。你可以带上或不带 ${{ }} 封装来写它。
🌐 The value is a boolean or an expression string. You can write it with or without the ${{ }} wrapper.
on: pull_request: if: ${{ !github.event.pull_request.draft }}
这个表达式必须放在一个 ${{ }} 块中，并且最多只能有 250 个字符。
🌐 The expression must fit in one ${{ }} block and can be at most 250 characters.
当条件评估为假时，不会为该触发事件启动任何工作流运行。对现有运行的重试会跳过此检查。它仅在创建新运行时适用。
🌐 When the condition evaluates to false, no workflow run starts for that trigger event. A retry of an existing run skips this check. It only applies when a new run is created.
该表达式可以使用 github、app_store_connect、inputs、workflow、app 和 account 上下文。它支持所有 上下文函数，除了 success()、failure() 和 hashFiles()。这些函数需要已经运行过的作业或步骤，但触发器的 if 条件会在任何作业开始前进行评估。
🌐 The expression can use the github, app_store_connect, inputs, workflow, app, and account contexts. It supports all context functions except success(), failure(), and hashFiles(). Those functions need a job or step that has already run, but a trigger's if condition evaluates before any job starts.
on: push: if: ${{ github.ref_name == 'main' }} pull_request_comment: if: ${{ startsWith(github.event.comment.body, '/deploy') }}
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:
productionpreviewdevelopment
environment 键在所有任务中都可用。如果省略它，默认值取决于任务类型：build 任务会从 eas.json 中构建配置文件的 environment 推断，submit 任务会继承已提交构建的值，maestro 和 maestro-cloud 任务默认是 preview，其他所有任务默认是 production。详情请参见 任务环境。
🌐 The environment key is available on all jobs. When you omit it, the default depends on the job type: 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, and all other jobs default to production. See The job environment for details.
jobs: my_job: environment: production | preview | development
jobs.<job_id>.env
为作业设置环境变量。此属性可用于所有运行虚拟机的作业（除预打包的 apple-device-registration-request、branch-delete、doc、get-build、github-comment、require-approval、slack 和 update-rollout 作业外的所有作业）。
🌐 Sets environment variables for the job. The property is available on all jobs running a VM (all jobs except for the pre-packaged apple-device-registration-request, branch-delete, doc, get-build, github-comment, require-approval, slack, and update-rollout jobs).
jobs: my_job: env: APP_VARIANT: staging RETRY_COUNT: 3 PREV_JOB_OUTPUT: ${{ needs.previous_job.outputs.some_output }}
jobs.<job_id>.hooks
以下预打包的任务支持在主要任务操作之前或之后运行额外步骤的钩子：build、deploy、fingerprint、maestro、maestro-cloud、repack、submit、testflight 和 update。钩子名称是针对特定任务的。请查看任务文档了解可用的钩子键。要为工作流中的所有任务设置默认钩子，请使用 defaults.hooks。钩子步骤可以像任务步骤一样调用 自定义函数。
🌐 The following pre-packaged jobs support hooks to run additional steps before or after the main job action: build, deploy, fingerprint, maestro, maestro-cloud, repack, submit, testflight, and update. Hook names are job-specific. See the job's documentation for the available hook keys. To set default hooks for all jobs in the workflow, use defaults.hooks. Hook steps can call custom functions just as job steps can.
jobs: maestro_test: type: maestro-cloud params: build_id: ${{ needs.build.outputs.build_id }} maestro_project_id: proj_xyz flows: ./maestro/flows hooks: before_maestro_cloud: - run: echo "Before upload" after_maestro_cloud: - run: echo "After upload"
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.hooks
工作流中所有任务的默认钩子。每个任务只运行适用的钩子键，其他的会被忽略。任务级别的钩子键会覆盖 defaults.hooks 中相同的键。要让某个任务不使用默认钩子，只需将该键设为空数组。默认钩子步骤也可以调用自定义函数。
🌐 Default hooks for all jobs in the workflow. Each job runs the hook keys that apply to it and ignores the rest. A job-level hook key overrides the same key from defaults.hooks. To opt a single job out of a default hook, set the key to an empty array. Default hook steps can also call custom functions.
defaults: hooks: before_install_node_modules: - name: Configure private registry run: echo "//npm.pkg.github.com/:_authToken=$GITHUB_TOKEN" >> .npmrc jobs: build_app: type: build params: platform: ios publish_update: type: update hooks: before_install_node_modules: [] # opt this job out of the default hook
defaults.image
工作流中所有作业默认使用的虚拟机镜像。推荐使用 sdk-XX 镜像标签。可用镜像请参见 基础设施。单个作业可以使用 jobs.<job_id>.image 覆盖此值。
defaults: image: sdk-57
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:
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?: { action?: string; label?: { name: string; }; // Only available for push and schedule events head_commit?: { message: string; id: string; }; pull_request?: { number: number; title: string; body: string | null; state: 'open' | 'closed'; draft: boolean; merged: boolean | null; // ... Other fields from the GitHub Pull Request webhook payload }; comment?: { body: string; // ... Other fields from the GitHub issue_comment webhook payload }; changes?: { base?: { ref?: { from: string; }; }; }; number?: number; schedule?: string; inputs?: Record<string, string | number | boolean>; }; };
信息
event对象包含完整的 GitHub webhook 载荷。对于pull_request事件，event.pull_request包含来自 GitHub 拉取请求 webhook 载荷的字段，比如github.event.pull_request.title和github.event.pull_request.body。对于已编辑的拉取请求事件，github.event.changes包含已更改的字段，比如当基础分支更改时的github.event.changes.base.ref.from。对于pull_request_comment事件，event.comment.body包含评论文本，而event.pull_request.number和event.number包含拉取请求编号。上面的类型列出了一些有用的字段，但额外的字段如user、labels、milestone等也可以使用。
如果从 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
查看 ${{ github }} 定义的源代码。
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 }}
app
关于 EAS 项目的信息，工作流程会为其运行。每次工作流程运行时都可以获得这个上下文。
🌐 Information about the EAS project the workflow runs for. This context is available in every workflow run.
type AppContext = { id: string; slug: string; };
示例：
🌐 Example:
jobs: print_context: steps: - run: echo "Project ${{ app.slug }} (${{ app.id }})"
account
有关拥有该项目的账户的信息。每次工作流运行时都可以获取这个上下文。
🌐 Information about the account that owns the project. This context is available in every workflow run.
type AccountContext = { id: string; name: string; };
示例：
🌐 Example:
jobs: print_context: steps: - run: echo "Account ${{ account.name }} (${{ account.id }})"
app_store_connect
与工作流运行相关的 App Store Connect 实体的信息。此上下文仅适用于由 App Store Connect 事件触发的工作流。参见 on.app_store_connect。
🌐 Information about App Store Connect entities associated with the workflow run. This context is available only for workflows triggered by an App Store Connect event. See on.app_store_connect.
type AppStoreConnectContext = { app: { id: string; }; build_upload?: { id: string; state: 'awaiting_upload' | 'processing' | 'failed' | 'complete'; cf_bundle_version?: string; cf_bundle_short_version_string?: string; platform?: string; uploaded_date?: string; created_date?: string; build?: { id: string; }; }; app_version?: { id: string; state: string; }; external_beta?: { id: string; state: string; }; beta_feedback?: { id: string; type: 'crash' | 'screenshot'; url: string; }; };
只有在工作流由 build_upload 事件域触发时，app_store_connect.build_upload 对象才存在。
🌐 The app_store_connect.build_upload object is present only when the workflow is triggered by a build_upload event domain.
示例：
🌐 Example:
on: app_store_connect: build_upload: states: - complete jobs: notify: type: slack params: webhook_url: ${{ env.SLACK_WEBHOOK_URL }} message: | Upload complete for App Store Connect app: ${{ app_store_connect.app.id }} Upload ID: ${{ app_store_connect.build_upload.id }} Upload state: ${{ app_store_connect.build_upload.state }} Version: ${{ app_store_connect.build_upload.cf_bundle_short_version_string }} (${{ app_store_connect.build_upload.cf_bundle_version }})
将 build_upload.build.id 用作 testflight 作业的 asc_build_id：
🌐 Use build_upload.build.id as the asc_build_id for a testflight job:
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 refresh_ad_hoc_provisioning_profile: boolean # optional hooks: before_install_node_modules: step[] # optional after_install_node_modules: step[] # 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 source_maps: boolean # optional hooks: after_checkout: step[] # optional before_install_node_modules: step[] # optional after_install_node_modules: step[] # 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 hooks: after_checkout: step[] # optional before_install_node_modules: step[] # optional after_install_node_modules: step[] # optional
此作业输出以下属性：
🌐 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 hooks: after_checkout: step[] # optional before_install_node_modules: step[] # optional after_install_node_modules: step[] # optional before_submit: step[] # optional after_submit: step[] # 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 的内部和外部测试组。请准确提供 build_id（上传构建并提交到 TestFlight）或 asc_build_id（提交已上传的构建）之一。有关详细信息和示例，请参阅TestFlight 作业文档。
🌐 Distributes iOS builds to TestFlight internal and external testing groups. Provide exactly one of build_id (upload a build and submit to TestFlight) or asc_build_id (submit an already uploaded build). See TestFlight job documentation for detailed information and examples.
jobs: my_job: type: testflight params: build_id: string # required to upload and submit to TestFlight; mutually exclusive with asc_build_id profile: string # optional, default: production; only when uploading and submitting wait_processing_timeout_seconds: number # optional, default: 1800 (30 minutes); only when uploading and submitting in one job asc_build_id: string # required to submit an already uploaded build; mutually exclusive with build_id internal_groups: string[] # optional external_groups: string[] # optional changelog: string # optional submit_beta_review: boolean # optional hooks: # only when uploading and submitting with build_id after_checkout: step[] # optional before_install_node_modules: step[] # optional after_install_node_modules: step[] # optional
这个作业会输出以下属性，其中 asc_build_id 只会在提交已经上传的构建时设置：
🌐 This job outputs the following properties, where asc_build_id is only set when submitting an already uploaded build:
{ "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 "asc_build_id": string | null // App Store Connect build ID. Only when submitting an already uploaded build. }
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 rollout_percentage: number # optional - 0 to 100, defaults to 100 private_key_path: string # optional upload_sentry_sourcemaps: boolean # optional - defaults to "try uploading, but don't fail the job if it fails" hooks: after_checkout: step[] # optional before_install_node_modules: step[] # optional after_install_node_modules: step[] # optional before_update: step[] # optional after_update: step[] # optional
此作业输出以下属性：
🌐 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`. }
update-rollout
增加正在进行的 EAS 更新推送的覆盖百分比。有关详细信息和示例，请参见更新推送作业文档。
🌐 Increases the rollout percentage of an in-progress EAS Update rollout. See Update rollout job documentation for detailed information and examples.
jobs: my_job: type: update-rollout params: update_group_id: string # required rollout_percentage: number # optional - 0 to 100, defaults to 100
此作业输出以下属性：
🌐 This job outputs the following properties:
{ "update_group_id": string, // ID of the update group that was rolled out. "rollout_percentage": string, // The rollout percentage that was applied to the update group. "updates_json": string // Stringified JSON array of the updates in the group. }
branch-delete
删除一个 EAS 更新分支及其所有更新。有关详细信息和示例，请参阅分支删除作业文档。
🌐 Deletes an EAS Update branch and all of its updates. See Branch delete job documentation for detailed information and examples.
jobs: my_job: type: branch-delete params: branch_name: string # required fail_on_missing: boolean # optional, default: false
此作业输出以下属性：
🌐 This job outputs the following properties:
{ "branch_id": string | null, "branch_name": string }
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/build-reference/infrastructure/ for a list of available images. runs_on: string # optional. Use a linux-*-nested-virtualization worker for Android Emulator tests. See https://expo.nodejs.cn/eas/workflows/syntax/#jobsjob_idruns_on for available options. params: build_id: string # required flow_path: string | string[] # required shards: number # optional, defaults to 1 retries: number # optional, defaults to 0 retry_failed_only: boolean # optional, defaults to true. When true, retries will attempt to re-run only the flows that failed on the previous attempt when applicable. 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, defaults to junit. Maestro test report format. Will be passed to Maestro as `--format`. Can be `junit` or other supported formats. skip_build_check: boolean # optional, defaults to false. Skip validation of the build (whether an iOS build is a simulator build). hooks: after_checkout: step[] # optional before_maestro_tests: step[] # optional after_maestro_tests: step[] # optional
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 账户和 Cloud 计划订阅。访问 Maestro 文档 了解更多信息。
jobs: my_job: type: maestro-cloud environment: production | preview | development # optional, defaults to preview image: string # optional. See https://expo.nodejs.cn/build-reference/infrastructure/ 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. 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`. device_model: string # optional. Model of the device to use for the tests. Will be passed to Maestro as `--device-model`. Run `maestro list-cloud-devices` 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 list-cloud-devices` for a list of supported values. skip_build_check: boolean # optional, defaults to false. Skip validation of the build (whether an iOS build is a simulator build). 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`. hooks: after_checkout: step[] # optional. Steps to run after the job checks out your project. before_maestro_cloud: step[] # optional. Steps to run before the Maestro Cloud upload. after_maestro_cloud: step[] # optional. Steps to run after the Maestro Cloud upload.
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 }
apple-device-registration-request
暂停工作流程，直到 iOS 设备注册到 Apple 团队并且团队成员批准注册。有关详细信息和示例，请参见 Apple 设备注册请求作业文档。
🌐 Pauses the workflow until an iOS device enrolls for an Apple team and a team member approves the enrollment. See Apple device registration request job documentation for detailed information and examples.
jobs: register_device: type: apple-device-registration-request params: apple_team_identifier: string # optional
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 js_bundle_only: boolean # optional ios_signing_use_source_app_entitlements: boolean # optional ios_signing_app_entitlements_path: string # optional message: string # optional repack_version: string # optional repack_package: string # optional hooks: after_checkout: step[] # optional before_install_node_modules: step[] # optional after_install_node_modules: step[] # 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
指定将执行该任务的工作者。适用于自定义任务以及 build、maestro、maestro-cloud 和 repack 预打包任务。
🌐 Specifies the worker that will execute the job. Available on custom jobs and on the build, maestro, maestro-cloud, and repack pre-packaged 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
你可以在你的项目中定义可重用的步骤序列，并使用以 ./ 或 ../ 开头的路径来调用它们，例如 ./.eas/functions/setup。查看 自定义函数模式 以及关于 在 EAS 工作流中使用自定义函数 的指南。
🌐 You can define reusable step sequences in your project and call them with a path that starts with ./ or ../, such as ./.eas/functions/setup. See the custom function schema and the guide to using custom functions in EAS Workflows.
以下是你可以在工作流步骤中使用的内置函数列表。
🌐 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
对于使用 Git 项目源的作业，该步骤默认使用作业记录的提交。使用 ref 可以签出不同的分支、标签或提交：
🌐 For jobs with Git-based project sources, the step uses the job's recorded commit by default. Use ref to check out a different branch, tag, or commit:
jobs: my_job: steps: - uses: eas/checkout with: ref: feature/add-icon
ref 接受：
- 一个分支，可以是像
feature/add-icon这样的裸名称，也可以是像refs/heads/feature/add-icon这样的限定引用。仓库最终会在该分支上。 - 一个标签，作为像
refs/tags/v1.2.3这样的限定引用。仓库最终处于分离的HEAD上。 - 一个完整的提交 SHA。仓库最终会处于分离的
HEAD状态。
这一步会从源仓库的 origin 执行一次浅拉取（--depth 1），所以引用必须能在那里访问到。
🌐 The step runs a shallow fetch (--depth 1) from the source repository's origin, so the ref must be reachable there.
ref 仅在你的项目来源于 Git 仓库时才有效，例如通过 GitHub 集成触发的任务。本地构建和上传的项目压缩包不支持。请在任务的第一个 eas/checkout 步骤中设置 ref。如果在之后的步骤中设置会失败，因为项目已经被检出了。
在 GitHub 上查看 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.
在 GitHub 上查看 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"].
输出
🌐 Outputs
在 GitHub 上查看 eas/download_build 函数的源代码。
用法示例：
🌐 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 }}
在 GitHub 上查看 eas/prebuild 函数的源代码。
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
在 GitHub 上查看 eas/restore_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
在 GitHub 上查看 eas/save_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 }}。
🌐 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 sent to a Slack channel' slack_hook_url: ${{ env.ANOTHER_SLACK_HOOK_URL }}
在 GitHub 上查看 eas/send_slack_message 函数的源代码。
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.
在 GitHub 上查看 eas/use_npm_token 函数的源代码。
eas/upload_artifact
将作业工作区中的文件作为附加到工作流运行的制品上传。上传的制品会出现在运行的 Artifacts 部分，并可以在后续作业中使用 eas/download_artifact 检索。
🌐 Uploads files from the job's workspace as an artifact attached to the workflow run. Uploaded artifacts appear in the run's Artifacts section and can be retrieved in a later job with eas/download_artifact.
信息 在自定义（非构建）作业中，将
type: other设置为上传通用工件。application-archive和build-artifact类型保留给构建作业 —— 在自定义作业中使用它们会导致类似Uploading application archives outside of builds is not supported的错误。
jobs: my_job: steps: - uses: eas/checkout - name: Run tests run: ./scripts/run-tests.sh # writes results into ./results - uses: eas/upload_artifact if: ${{ always() }} with: type: other name: test-results path: | results/**/*
属性
🌐 Properties
输出
🌐 Outputs
在 GitHub 上查看 eas/upload_artifact 函数的源代码。
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
在 GitHub 上查看 eas/download_artifact 函数的源代码。
示例
🌐 Example
jobs: maestro_tests: type: maestro params: build_id: '123-abc' flow_path: 'path/to/flow.yaml' 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 }}
以下功能将你的工作流连接到 PostHog。运行 eas integrations:posthog:connect 以关联一个 PostHog 项目并设置这些功能读取的环境变量。eas/posthog_capture_event 使用你的公共项目 API 密钥，而其他功能使用带有各自权限范围的 PostHog 个人 API 密钥。有关设置，请参阅 使用 PostHog，有关完整工作流，请参阅 EAS 工作流的 PostHog 使用示例。
🌐 The following functions connect your workflow to PostHog. Run eas integrations:posthog:connect to link a PostHog project and set the environment variables these functions read. eas/posthog_capture_event uses your public project API key, while the other functions use a PostHog personal API key with the scopes noted for each one. For setup, see Using PostHog, and for complete workflows, see PostHog recipes for EAS Workflows.
eas/posthog_capture_event
向 PostHog 发送一个分析事件。用它来标记你的构建、发布以及 PostHog 时间线上的其他重要节点。
🌐 Sends an analytics event to PostHog. Use it to mark builds, releases, and other milestones on your PostHog timeline.
当你没有提供 distinct_id 时，事件会匿名发送，并且不会创建 PostHog 个人资料，这样可以让工作流程事件不会出现在你的人列表中。
🌐 When you do not provide a distinct_id, the event is sent anonymously and does not create a PostHog person profile, which keeps workflow events out of your list of people.
jobs: my_job: steps: - uses: eas/posthog_capture_event with: event: ota_update_published properties: branch: main
属性
🌐 Properties
在 GitHub 上查看 eas/posthog_capture_event 函数的源代码。
eas/posthog_flag_rollout
启用、禁用或推出一个 PostHog 功能标志。该函数通过键查找标志，然后更新它。至少提供 active、rollout_percentage 或 payload 中的一个。
🌐 Enables, disables, or rolls out a PostHog feature flag. The function looks up the flag by key and then updates it. Provide at least one of active, rollout_percentage, or payload.
jobs: my_job: steps: - uses: eas/posthog_flag_rollout with: flag: new-checkout rollout_percentage: 25
属性
🌐 Properties
在 GitHub 上查看 eas/posthog_flag_rollout 函数的源代码。
eas/posthog_wait_for_metric
暂停工作流，直到一个 HogQL 查询返回满足比较条件的数字。可以用它来根据指标控制发布，例如一直等待，直到过去几分钟的错误数量保持在低位。
🌐 Pauses the workflow until a HogQL query returns a number that satisfies a comparison. Use it to gate a rollout on a metric, such as holding until the error count over the last few minutes stays low.
这个函数每隔 interval_seconds 运行一次查询，直到比较结果为真或者 timeout_seconds 时间过去。如果查询无法读取，比如无效的 HogQL，会立即失败，而临时性错误会一直重试直到超时。
🌐 The function runs the query every interval_seconds until the comparison is true or timeout_seconds elapses. A query that cannot be read, such as invalid HogQL, fails the step immediately, while transient errors are retried until the timeout.
信息 这一步没有
ignore_error输入。超时或无法读取的查询总会导致步骤失败。
jobs: my_job: steps: - uses: eas/posthog_wait_for_metric with: query: SELECT count() FROM events WHERE event = '$exception' AND timestamp > now() - INTERVAL 15 MINUTE operator: lt threshold: 10
属性
🌐 Properties
输出
🌐 Outputs
在 GitHub 上查看 eas/posthog_wait_for_metric 函数的源代码。
eas/posthog_wait_for_query
暂停工作流程，直到 HogQL 查询返回 true。当条件在查询中更容易表达时使用它。如果是带有明确阈值的数字比较，请改用 eas/posthog_wait_for_metric。
🌐 Pauses the workflow until a HogQL query returns true. Use it when the condition is easier to express in the query itself. For a numeric comparison with an explicit threshold, use eas/posthog_wait_for_metric instead.
当第一行的第一列是 true 或一个非零数字时，这一步就完成了，所以写一个查询来选择一个布尔值，比如 SELECT count() > 100 FROM events。
🌐 The step clears when the first column of the first row is true or a nonzero number, so write the query to select a single boolean, such as SELECT count() > 100 FROM events.
信息 像
eas/posthog_wait_for_metric一样，这一步没有ignore_error输入。超时或无法读取的查询总会导致这一步失败。
jobs: my_job: steps: - uses: eas/posthog_wait_for_query with: query: SELECT count() > 0 FROM events WHERE event = 'smoke_test_passed' AND timestamp > now() - INTERVAL 30 MINUTE
属性
🌐 Properties
在 GitHub 上查看 eas/posthog_wait_for_query 函数的源代码。
eas/posthog_annotation
在项目时间线上创建一个 PostHog 注释。注释会显示在你的 PostHog 图表上，这样它们就可以用来在受影响的指标旁标记构建、发布和其他里程碑。
🌐 Creates a PostHog annotation on the project timeline. Annotations show up on your PostHog charts, which makes them useful for marking builds, releases, and other milestones next to the metrics they affect.
jobs: my_job: steps: - uses: eas/posthog_annotation with: content: Published update to production
属性
🌐 Properties
在 GitHub 上查看 eas/posthog_annotation 函数的源代码。
eas/posthog_upload_sourcemaps
将 JavaScript 源映射上传到 PostHog，以便 PostHog 在错误跟踪中符号化堆栈跟踪。在生成 bundle 的步骤之后，在同一个任务中运行它，这样 bundle 和源映射就会保存在磁盘上。使用 npx expo export --source-maps 导出，并根据源映射指南配置 PostHog 的 Metro 配置，这样 bundle 就会包含与其源映射匹配的 chunk ID。
🌐 Uploads JavaScript source maps to PostHog so that PostHog symbolicates stack traces in error tracking. Run it after the step that produces your bundle, in the same job, so the bundle and source maps are available on disk. Export with npx expo export --source-maps, and configure the PostHog Metro config from the Source maps guide so bundles carry the chunk IDs that match them to their source maps.
警告 这一步会运行 PostHog CLI，它无法区分权限错误和其他任何失败。与其他 PostHog 功能不同，设置
ignore_error: true也会隐藏认证和权限范围错误。
jobs: publish_update: steps: - uses: eas/checkout - uses: eas/install_node_modules - run: npx expo export --source-maps - uses: eas/posthog_upload_sourcemaps with: directory: dist
属性
🌐 Properties
在 GitHub 上查看 eas/posthog_upload_sourcemaps 函数的源代码。
自定义函数
🌐 Custom functions
在你的项目中定义可重用的步骤序列，并通过 uses 使用相对路径调用它们。路径必须是静态的字面字符串，不能包含 ${{ }} 插值或反斜杠。自定义函数调用接受与内置函数调用相同的字段：id、name、with、if 和 env。不要在调用步骤上设置 working_directory，而是应该在函数的内部步骤中设置它。将每个自定义函数存储在包含 function.yml 或 function.yaml 文件的目录中。自定义函数中的步骤使用与 自定义作业步骤 相同的格式。关于文件组织、函数嵌套以及从作业或钩子调用函数的详细信息，请参阅 EAS Workflows 中的自定义函数。
🌐 Define reusable step sequences in your project and call them with a relative path through uses. The path must be a static, literal string. It cannot contain ${{ }} interpolation or backslashes. Custom function calls accept the same fields as built-in function calls: id, name, with, if, and env. Do not set working_directory on the call step. Set it on the function's inner steps instead. Store each custom function in a directory that contains a function.yml or function.yaml file. Steps inside a custom function use the same format as custom job steps. For details about organizing files, nesting functions, and calling functions from jobs or hooks, see Custom functions in EAS Workflows.
你的 function.yml 文件支持以下顶层属性：name、description、inputs、outputs 和 runs。EAS 工作流会拒绝未知的顶层属性。
🌐 Your function.yml file supports the following top-level properties: name, description, inputs, outputs, and runs. EAS Workflows rejects unknown top-level properties.
函数 name
🌐 Function name
自定义函数的可选显示名称，会出现在作业日志中。
🌐 An optional display name for the custom function that appears in job logs.
name: Greet
函数 description
🌐 Function description
对自定义函数功能的可选描述。
🌐 An optional description of what the custom function does.
description: Prints a greeting for the given name.
函数 inputs
🌐 Function inputs
输入值是调用者可以通过 with: 传递给自定义函数的。你可以用两种方式声明输入。
🌐 Input values a caller can pass to the custom function with with:. You can declare inputs two ways.
简写形式是一个名字列表。每个输入都会变成一个可选的字符串输入，没有默认值：
🌐 The shorthand form is a list of names. Each input becomes an optional string input with no default value:
inputs: - who
完整形式是一个包含以下属性的对象列表：
🌐 The full form is a list of objects with the following properties:
inputs: - name: who type: string default_value: world - name: platform type: string allowed_values: [android, ios] required: true
在自定义函数的步骤中，用 ${{ inputs.<name> }} 读取一个输入。
函数 outputs
🌐 Function outputs
把自定义函数向调用者暴露的输出值声明为以输出名称为键的映射：
🌐 Declare the output values that the custom function exposes to its caller as a map keyed by output name:
outputs: message: value: '${{ steps.make.outputs.message }}' description: The rendered greeting.
EAS 工作流将每个输出都显示为字符串。把输出读作 ${{ steps.<call_id>.outputs.<name> }}。使用调用步骤中的 id。调用方无法引用函数的内部步骤标识符。
函数 runs.steps
🌐 Function runs.steps
runs.steps 是必填项，并且必须至少包含一个步骤。步骤的格式与 自定义作业步骤 相同，包括 id、run、uses、if 和 working_directory。目前，自定义函数无法调用 eas/build 或 eas/maestro_test。
runs: steps: - id: make run: set-output message "Hello, ${{ inputs.who }}!"
内置 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