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 工作流中设置和使用预打包的作业。
预封装作业是现成可用的工作流作业，可帮助你自动执行常见任务，例如构建、提交和测试应用。它们提供了一种标准化的方法来处理这些操作，而无需从头编写自定义作业配置。本指南介绍了可用的预封装作业以及如何在工作流中使用它们。
🌐 Pre-packaged jobs are ready-to-use workflow jobs that help you automate common tasks like building, submitting, and testing your app. They provide a standardized way to handle these operations without having to write custom job configurations from scratch. This guide covers the available pre-packaged jobs and how to use them in your workflows.
构建
🌐 Build
将你的项目构建成 Android 或 iOS 应用。
🌐 Build your project into an Android or iOS app.
构建作业可以自定义，以便在构建过程中执行自定义命令。有关更多信息，请参见自定义构建。
🌐 Build jobs can be customized so that you can execute custom commands during the build process. See Custom builds for more information.
1 要求
1 要求
你的项目必须为 EAS Build 进行设置：eas.json 必须包含作业使用的构建配置文件，并且必须为该平台配置应用签名凭据。可以通过使用作业相同的平台和配置文件运行 eas credentials:configure-build -p <platform> -e <profile> 来设置凭据，而无需先运行构建。了解有关为 EAS Build 配置项目的更多信息。
语法
🌐 Syntax
jobs: build_app: type: build runs_on: string # optional - see https://expo.nodejs.cn/build-reference/infrastructure/ for available options params: platform: android | ios # required profile: string # optional - default: production message: string # optional refresh_ad_hoc_provisioning_profile: boolean # optional hooks: before_install_node_modules: step[] # optional - steps to run before the build installs dependencies. after_install_node_modules: step[] # optional - steps to run after the build installs dependencies.
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
环境变量
🌐 Environment variables
如果在构建过程中需要某些环境变量，你可以将它们包含在你的 eas.json 中，针对你指定的构建 profile。这些变量将从 EAS 环境变量 中获取。
🌐 If you need certain environment variables during the build process, you can include them in your eas.json, for your specified build profile. They will be pulled from EAS environment variables.
输出
🌐 Outputs
你可以在后续作业中引用以下输出：
🌐 You can reference the following outputs in subsequent jobs:
钩子
🌐 Hooks
以下钩子支持用于构建任务：
🌐 The following hooks are supported for the Build job:
before_install_node_modules：在构建安装你项目的依赖之前要运行的步骤。after_install_node_modules：在构建安装完项目依赖后要执行的步骤。
有关通用 hooks 语法，请参见 jobs.<job_id>.hooks。
示例
🌐 Examples
以下是一些使用构建作业的实际示例：
🌐 Here are some practical examples of using the build job:
特定平台的基本构建
每当你推送到主分支时，这个工作流程会构建你的 iOS 应用。
🌐 This workflow builds your iOS app whenever you push to the main branch.
同时为两个平台构建
当你推送到主分支时，此工作流会同时构建 Android 和 iOS 应用。
🌐 This workflow builds both Android and iOS apps in parallel when you push to the main branch.
使用环境变量构建
此工作流程使用自定义环境变量构建你的 Android 应用，这些变量可以在构建过程中使用。
🌐 This workflow builds your Android app with custom environment variables that can be used during the build process.
使用不同的配置构建
此工作流使用不同的配置创建两个不同的 Android 构建版本——一个用于内部分发，另一个用于通过开发和生产配置进行商店提交。
🌐 This workflow creates two different Android builds using different profiles - one for internal distribution and one for store submission using the development and production profiles.
使用更新后的临时配置文件的内部 iOS 构建
此工作流程会为内部分发构建你的 iOS 应用，并在你推送到主分支时刷新临时配置文件。
🌐 This workflow builds your iOS app for internal distribution and refreshes the ad hoc provisioning profile when you push to the main branch.
部署
🌐 Deploy
使用 EAS Hosting 部署你的应用。
🌐 Deploy your application using EAS Hosting.
1 要求
1 要求
有关设置说明，请参阅 开始使用 EAS 托管
语法
🌐 Syntax
jobs: deploy_web: type: deploy params: alias: string # optional prod: boolean # optional source_maps: boolean # optional hooks: after_checkout: step[] # optional - steps to run after the job checks out your project. before_install_node_modules: step[] # optional - steps to run before the job installs dependencies. after_install_node_modules: step[] # optional - steps to run after the job installs dependencies.
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
输出
🌐 Outputs
你可以在后续作业中引用以下输出：
🌐 You can reference the following outputs in subsequent jobs:
钩子
🌐 Hooks
部署任务支持以下钩子：
🌐 The following hooks are supported for the Deploy job:
after_checkout：在工作检查完你的项目后要采取的步骤。before_install_node_modules：在工作安装你项目的依赖之前要运行的步骤。after_install_node_modules：在作业安装完你项目的依赖后要执行的步骤。
有关通用 hooks 语法，请参见 jobs.<job_id>.hooks。
示例
🌐 Examples
以下是一些使用部署任务的实际示例：
🌐 Here are some practical examples of using the deploy job:
基本部署到生产环境
此工作流程使用 EAS Hosting 将你的应用部署到生产环境。
🌐 This workflow deploys your application to production using EAS Hosting.
仅在合并到 `main` 分支时部署到生产环境
当你合并到主分支时，此工作流会将你的应用部署到生产环境，并在其他所有分支上进行非生产环境部署。
🌐 This workflow deploys your application to production when you merge to the main branch, and makes a non-production deployment on all other branches.
使用自定义别名的部署
此工作流程将你的应用部署到生产环境中的自定义别名。
🌐 This workflow deploys your application to a custom alias in production.
指纹
🌐 Fingerprint
计算项目的指纹。
🌐 Calculates a fingerprint of your project.
注意： 此工作类型仅支持 CNG 工作流程。如果你提交了 android 或 ios 目录，指纹工作将无法运行。
语法
🌐 Syntax
jobs: fingerprint: type: fingerprint environment: production | preview | development # optional, defaults to production env: # optional list of environment variables ENV_VAR_NAME: value hooks: after_checkout: step[] # optional - steps to run after the job checks out your project. before_install_node_modules: step[] # optional - steps to run before the job installs dependencies. after_install_node_modules: step[] # optional - steps to run after the job installs dependencies.
环境变量
🌐 Environment variables
你可以将一列环境变量传递给 env 参数。这些环境变量将从 EAS 环境变量 中提取。传递的 environment 参数将用于环境变量的环境，这在相同的环境变量在不同环境中定义时非常有用。
🌐 You can pass a list of environment variables into the env parameter. These environment variables will be pulled from EAS environment variables. The passed environment parameter will be used for the environment variable's environment, which is useful when the same environment variable is defined across different environments.
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
输出
🌐 Outputs
你可以在后续作业中引用以下输出：
🌐 You can reference the following outputs in subsequent jobs:
钩子
🌐 Hooks
指纹任务支持以下钩子：
🌐 The following hooks are supported for the Fingerprint job:
after_checkout：在工作检查完你的项目后要采取的步骤。before_install_node_modules：在工作安装你项目的依赖之前要运行的步骤。after_install_node_modules：在作业安装完你项目的依赖后要执行的步骤。
有关通用 hooks 语法，请参见 jobs.<job_id>.hooks。
示例
🌐 Examples
以下是一些使用指纹作业的实际示例：
🌐 Here are some practical examples of using the fingerprint job:
基本指纹计算
此工作流会计算 Android 和 iOS 构建的指纹。environment 应与你的构建配置匹配，以确保指纹匹配准确。
🌐 This workflow calculates fingerprints for both Android and iOS builds. The environment should match your build profile for accurate fingerprint matching.
带内联环境变量的指纹
注意： 如果你依赖内联环境变量，你需要确保在每个地方（构建配置文件、指纹任务、更新任务等）都将正确的环境变量设置为正确的值，以使指纹匹配。我们建议使用EAS 环境变量，你可以在其中将一组变量分组到环境中，并在构建配置文件和工作流任务中引用它们。
获取构建
🌐 Get Build
从 EAS 检索与提供的参数匹配的现有构建。
🌐 Retrieve an existing build from EAS that matches the provided parameters.
语法
🌐 Syntax
jobs: get_build: 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
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
如果将 wait_for_in_progress 设置为 true，作业仍然会优先立即继续成功的构建，但它也会查找正在进行的构建。如果没有找到成功的构建，作业将等待正在进行的构建完成后再继续。如果匹配的构建成功，作业将被标记为成功，并返回成功的构建。如果匹配的构建失败，作业将被标记为成功，其输出将为空——就好像该构建未被匹配一样。
🌐 If wait_for_in_progress is set to true, the job will still prioritize continuing immediately with a successful build, but it will also look for in-progress builds. If no successful build is found, the job will wait for an in-progress build to complete before continuing. If the matched build succeeds, the job will be marked as successful and will return the successful build. If the matched build fails, the job will be marked as successful and its outputs will be empty — as if the build has not been matched.
输出
🌐 Outputs
你可以在后续作业中引用以下输出：
🌐 You can reference the following outputs in subsequent jobs:
示例
🌐 Examples
以下是使用 get-build 任务的一些实际示例：
🌐 Here are some practical examples of using the get-build job:
获取最新的生产版本
此工作流从商店分发渠道获取最新的 iOS 生产版本。
🌐 This workflow retrieves the latest production build for iOS from the store distribution channel.
按版本构建
此工作流程通过应用版本和构建版本检索特定版本的 Android 构建。
🌐 This workflow retrieves a specific version of an Android build by its app version and build version.
获取模拟器构建
此工作流程用于获取 iOS 开发的模拟器构建。wait_for_in_progress 设置为 true，以便如果已经存在匹配过滤器的构建，作业将在其完成之前等待。
🌐 This workflow retrieves a simulator build for iOS development. wait_for_in_progress is set to true so that if a build matching the filter already exists, the job will wait for it to complete before continuing.
提交
🌐 Submit
使用 EAS Submit 将 Android 或 iOS 版本提交到应用商店。
🌐 Submit an Android or iOS build to the app store using EAS Submit.
1 要求
1 要求
提交任务需要额外配置才能在 CI/CD 流程中运行。有关更多信息，请参阅 Google Play 商店 CI/CD 提交指南 和 Apple App Store CI/CD 提交指南。
语法
🌐 Syntax
jobs: submit_to_store: type: submit params: build_id: string # required profile: string # optional - default: production groups: string[] # optional hooks: after_checkout: step[] # optional - steps to run after the job checks out your project. before_install_node_modules: step[] # optional - steps to run before the job installs dependencies. after_install_node_modules: step[] # optional - steps to run after the job installs dependencies. before_submit: step[] # optional - steps to run before the submission starts. after_submit: step[] # optional - steps to run after the submission completes.
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
输出
🌐 Outputs
你可以在后续作业中引用以下输出：
🌐 You can reference the following outputs in subsequent jobs:
钩子
🌐 Hooks
提交作业支持以下钩子：
🌐 The following hooks are supported for the Submit job:
after_checkout：在工作检查完你的项目后要采取的步骤。before_install_node_modules：在工作安装你项目的依赖之前要运行的步骤。after_install_node_modules：在作业安装完你项目的依赖后要执行的步骤。before_submit：提交开始前要进行的步骤。after_submit：提交完成后的操作步骤。
有关通用 hooks 语法，请参见 jobs.<job_id>.hooks。
示例
🌐 Examples
以下是一些使用提交作业的实际示例：
🌐 Here are some practical examples of using the submit job:
提交 iOS 构建
此工作流程使用生产提交配置将 iOS 构建提交到 App Store。
🌐 This workflow submits an iOS build to the App Store using the production submit profile.
提交 Android 构建
此工作流程使用生产提交配置将 Android 构建提交到 Play 商店。
🌐 This workflow submits an Android build to the Play Store using the production submit profile.
TestFlight
将 iOS 构建分发给 TestFlight 内部和外部测试组。这是 iOS 提交任务的替代方案，当你需要更高级的 TestFlight 功能时可以使用。如果你需要管理测试组、更新日志或 Beta 应用审核提交，请使用 testflight 任务，而不是提交。
🌐 Distribute iOS builds to TestFlight internal and external testing groups. This is an alternative to the iOS submit job for when you need more advanced TestFlight features. If you need to control test groups, changelog, or Beta App Review submission, use the testflight job instead of submit.
该工作支持两种方法：上传构建并提交到 TestFlight（build_id），或提交已上传的构建（asc_build_id）。在两种情况下，你都可以将构建添加到群组，设置“测试内容”备注，并提交进行 Beta 应用审查。请仅提供 build_id 或 asc_build_id 中的一项。
🌐 The job supports two approaches: upload a build and submit it to TestFlight (build_id), or submit an already uploaded build (asc_build_id). In both cases, you can add the build to groups, set "What to Test" notes, and submit for Beta App Review. Provide exactly one of build_id or asc_build_id.
1 要求
1 要求
在分发给外部组或提交进行 Beta App 审核（external_groups 和/或 submit_beta_review: true）时，构建必须在作业成功之前在 App Store Connect 中完成所需的 TestFlight 测试信息。请参阅 Apple 文档中的提供测试信息。
共享参数
🌐 Shared parameters
这两种方法在 params 中接受以下参数：
🌐 Both approaches accept the following parameters in params:
上传构建并提交到 TestFlight
🌐 Upload build and submit to TestFlight
在单一工作流程任务中上传 EAS iOS 构建并提交到 TestFlight。
🌐 Upload an EAS iOS build and submit it to TestFlight in a single workflow job.
1 要求
1 要求
TestFlight 工作需要使用 distribution: store 创建的 iOS 构建以及已配置的 Apple 开发者账号。更多信息请参阅TestFlight 提交指南。
语法
🌐 Syntax
jobs: testflight_distribution: 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) hooks: after_checkout: step[] # optional - steps to run after the job checks out your project. before_install_node_modules: step[] # optional - steps to run before the job installs dependencies. after_install_node_modules: step[] # optional - steps to run after the job installs dependencies.
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
你也可以传递任何 共享参数。
🌐 You can also pass any of the shared parameters.
输出
🌐 Outputs
你可以在后续作业中引用以下输出：
🌐 You can reference the following outputs in subsequent jobs:
钩子
🌐 Hooks
TestFlight 任务支持以下钩子：
🌐 The following hooks are supported for the TestFlight job:
after_checkout：在工作检查完你的项目后要采取的步骤。before_install_node_modules：在工作安装你项目的依赖之前要运行的步骤。after_install_node_modules：在作业安装完你项目的依赖后要执行的步骤。
查看 jobs.<job_id>.hooks 了解一般的 hooks 语法。当 提交已上传的构建 时不支持 hooks，因为该作业类型不会在 worker 上运行。
示例
🌐 Examples
以下是一些使用 TestFlight 任务的实际示例：
🌐 Here are some practical examples of using the TestFlight job:
向内部和外部群体的完整分发
此工作流程会将更新分发到内部和外部 TestFlight 群组，并附带更新日志。
🌐 This workflow distributes to both internal and external TestFlight groups with a changelog.
仅上传更新日志
这个工作流程会上传一个带有更改日志的构建，但不会指定任何明确要添加构建的组。该构建只会被添加到启用了“自动分发”的内部组中。
🌐 This workflow uploads a build with a changelog but without specifying any groups to explicitly add the build to. The build will only get added to internal groups with "auto-distribute" enabled.
提交已上传的构建
🌐 Submit an already uploaded build
将已在 App Store Connect 中的构建提交到 TestFlight 群组，设置“测试内容”备注，并提交进行测试版应用审核。测试版应用审核提交是可选的。设置 submit_beta_review: false 可以在不重新提交审核的情况下更新现有构建的更新日志或群组。
🌐 Submit a build that is already in App Store Connect to TestFlight groups, set "What to Test" notes, and submit for Beta App Review. Beta App Review submission is optional. Set submit_beta_review: false to update the changelog or groups on an existing build without re-submitting it for review.
1 要求
1 要求
在 项目设置 > 常规 > 连接 中配置你的 App Store Connect 连接。构建必须已经存在于 App Store Connect 中并准备好提交。
语法
🌐 Syntax
jobs: testflight_distribution: type: testflight params: asc_build_id: string # required internal_groups: string[] external_groups: string[] changelog: string submit_beta_review: boolean
参数
🌐 Parameters
你也可以传递任何 共享参数。
🌐 You can also pass any of the shared parameters.
输出
🌐 Outputs
你可以在后续作业中引用以下输出：
🌐 You can reference the following outputs in subsequent jobs:
示例
🌐 Examples
在 App Store Connect 上传后自动分发到 TestFlight
当构建上传到 App Store Connect 时，该工作流程会自动将构建添加到 TestFlight 群组，设置“测试内容”说明，并提交进行 Beta 应用审核。使用此触发器之前，请配置你的 App Store Connect 连接。请参阅 从 App Store Connect 事件触发工作流程。
🌐 When a build is uploaded to App Store Connect, this workflow automatically adds the build to TestFlight groups, sets "What to Test" notes, and submits for Beta App Review. Configure your App Store Connect connection before using this trigger. See Trigger workflows from App Store Connect events.
${{ app_store_connect.build_upload.build.id }} 仅在工作流由 build_upload 事件触发且 App Store Connect 已将构建与上传关联时可用。build_upload.state: complete 表示上传已完成，而不是 App Store Connect 已完成构建处理。使用 external_groups 时，请先在 App Store Connect 中完成所需的 TestFlight 测试信息。
在不重新提交 Beta 应用审核的情况下更新更新日志
对于已经存在于 App Store Connect 的构建，你可以更新“测试内容”备注或组成员资格，而不会触发 Beta 应用审核。设置 submit_beta_review: false 可以应用更改，同时保持构建的现有审核状态不变。
🌐 For a build that already exists in App Store Connect, you can update the "What to Test" notes or group membership without triggering Beta App Review. Set submit_beta_review: false to apply the changes while leaving the build's existing review status untouched.
这个工作流将构建 ID 和新的更新日志作为手动输入，因此你可以使用 eas workflow:run 按需运行它。
🌐 This workflow takes the build ID and new changelog as manual inputs, so you can run it on demand with eas workflow:run.
更新
🌐 Update
使用 EAS Update 发布更新。
🌐 Publish an update using EAS Update.
1 要求
1 要求
用于发布更新预览和发送空中更新。运行 npx eas-cli@latest update:configure，然后创建新的构建。了解有关配置 EAS 更新的更多信息。
语法
🌐 Syntax
jobs: publish_update: type: update environment: production | preview | development # optional, defaults to production env: # optional list of environment variables ENV_VAR_NAME: value 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 - steps to run after the job checks out your project. before_install_node_modules: step[] # optional - steps to run before the job installs dependencies. after_install_node_modules: step[] # optional - steps to run after the job installs dependencies. before_update: step[] # optional - steps to run before publishing the update. after_update: step[] # optional - steps to run after publishing the update.
环境变量
🌐 Environment variables
你可以将一列环境变量传递给 env 参数。这些环境变量将从 EAS 环境变量 中提取。传递的 environment 参数将用于环境变量的环境，这在相同的环境变量在不同环境中定义时非常有用。
🌐 You can pass a list of environment variables into the env parameter. These environment variables will be pulled from EAS environment variables. The passed environment parameter will be used for the environment variable's environment, which is useful when the same environment variable is defined across different environments.
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
输出
🌐 Outputs
你可以在后续作业中引用以下输出：
🌐 You can reference the following outputs in subsequent jobs:
钩子
🌐 Hooks
Update 任务支持以下钩子：
🌐 The following hooks are supported for the Update job:
after_checkout：在工作检查完你的项目后要采取的步骤。before_install_node_modules：在工作安装你项目的依赖之前要运行的步骤。after_install_node_modules：在作业安装完你项目的依赖后要执行的步骤。before_update：发布更新前要做的步骤。after_update：发布更新后运行的步骤。Hook 步骤可以访问发布过程中生成的文件（例如 dist 目录中的 source map）。
有关通用 hooks 语法，请参见 jobs.<job_id>.hooks。
示例
🌐 Examples
以下是一些使用更新作业的实际示例：
🌐 Here are some practical examples of using the update job:
对生产通道的基本更新
每当你向主分支推送时，此工作流会将更新发布到生产渠道，并使用提交信息作为更新信息。
🌐 This workflow publishes an update to the production channel whenever you push to the main branch, using the commit message as the update message.
特定平台的更新
此工作流程为 Android 和 iOS 平台发布单独的更新，允许进行特定于平台的更改。
🌐 This workflow publishes separate updates for Android and iOS platforms, allowing for platform-specific changes.
使用基于分支的部署进行更新
此工作流程会根据分支名称发布更新，从而根据分支区分不同的环境（测试/生产）。
🌐 This workflow publishes updates based on the branch name, allowing for different environments (staging/production) based on the branch.
发布更新后上传源映射
这个工作流会发布一个更新，然后使用内置的 eas/posthog_upload_sourcemaps 函数将生成的源映射上传到 PostHog。发布更新会在 dist 目录中创建源映射，这是该函数默认的上传目录。这些文件只存在于运行该作业的工作节点上，所以上传必须在 after_update 钩子中进行，而不是在单独的作业中。钩子步骤会继承作业的环境，所以你可以将 POSTHOG_CLI_API_KEY 和 POSTHOG_CLI_PROJECT_ID 凭据作为 EAS 环境变量 提供。要上传到不同的服务，可以在 run 步骤中运行该服务的上传命令。
🌐 This workflow publishes an update and then uploads the generated sourcemaps to PostHog with the built-in eas/posthog_upload_sourcemaps function. Publishing an update creates sourcemaps in the dist directory, the function's default upload directory. These files only exist on the worker that runs the job, so the upload must happen in an after_update hook rather than in a separate job. Hook steps inherit the job's environment, so you can provide the POSTHOG_CLI_API_KEY and POSTHOG_CLI_PROJECT_ID credentials as EAS environment variables. To upload to a different service, run its upload command in a run step instead.
更新推送
🌐 Update rollout
增加正在进行的EAS 更新的推出比例。使用它来逐步向已经向部分用户发布了部分 rollout_percentage 的更新组推出更新。
🌐 Increase the rollout percentage of an in-progress EAS Update rollout. Use this to gradually roll out an update group that was published to a subset of users with a partial rollout_percentage.
语法
🌐 Syntax
jobs: roll_out_update: type: update-rollout params: update_group_id: string # required rollout_percentage: number # optional - 0 to 100, defaults to 100
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
输出
🌐 Outputs
你可以在后续作业中引用以下输出：
🌐 You can reference the following outputs in subsequent jobs:
示例
🌐 Examples
这里有一些使用更新推送任务的实用例子：
🌐 Here are some practical examples of using the update rollout job:
先发布部分版本，然后在批准后完成全部发布
这个工作流程会先向 25% 的用户发布更新，等待批准，然后才会完成向 100% 的用户的推送。
🌐 This workflow publishes an update to 25% of users, waits for approval, and only then completes the rollout to 100%.
删除分支
🌐 Branch delete
删除当前项目中的 EAS 更新 分支。与 eas branch:delete 相同。在 branch_name 中传递 EAS 更新分支名称。
🌐 Delete an EAS Update branch in the current project. The same as eas branch:delete. Pass the EAS Update branch name in branch_name.
语法
🌐 Syntax
jobs: delete_branch: type: branch-delete params: branch_name: string # required fail_on_missing: boolean # optional, default: false
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
输出
🌐 Outputs
你可以在后续作业中引用以下输出：
🌐 You can reference the following outputs in subsequent jobs:
示例
🌐 Examples
请参见 清理更新分支示例 了解一个使用 on.ref_delete 和 branch-delete 任务的工作流程。
🌐 See Clean up update branches example for a workflow that uses on.ref_delete with the branch-delete job.
大师
🌐 Maestro
在 Android 模拟器或 iOS 模拟器构建上运行 Maestro 测试。
🌐 Run Maestro tests on an Android Emulator or iOS Simulator build.
重要 Maestro 测试处于 alpha 阶段。
语法
🌐 Syntax
jobs: run_maestro_tests: 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 record_screen: boolean # optional - defaults to false include_tags: string | string[] # optional exclude_tags: string | string[] # optional maestro_version: string # optional - defaults to latest android_system_image_package: string # optional device_identifier: string | { android?: string, ios?: string } # optional output_format: string # optional - defaults to junit skip_build_check: boolean # optional - defaults to false hooks: after_checkout: step[] # optional - steps to run after the job checks out your project. before_maestro_tests: step[] # optional - steps to run before the tests start. after_maestro_tests: step[] # optional - steps to run after the tests complete.
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
钩子
🌐 Hooks
Maestro 作业支持以下钩子：
🌐 The following hooks are supported for the Maestro job:
after_checkout：在工作检查完你的项目后要采取的步骤。before_maestro_tests：在测试开始前要执行的步骤。after_maestro_tests：测试完成后的运行步骤。
有关通用 hooks 语法，请参见 jobs.<job_id>.hooks。
示例
🌐 Examples
以下是一些使用 Maestro 任务的实际示例：
🌐 Here are some practical examples of using the Maestro job:
基础大师测试
此工作流使用默认设置在 iOS 模拟器构建上运行 Maestro 测试。
🌐 This workflow runs Maestro tests on an iOS Simulator build using the default settings.
Maestro 分片测试
这个工作流程在一个带有3个分片和对失败测试进行2次重试的Android模拟器构建上运行Maestro测试。
🌐 This workflow runs Maestro tests on an Android Emulator build with 3 shards and 2 retries for failed tests.
使用 Maestro 前缀的环境变量
当变量前缀为 MAESTRO_ 时，Maestro 可以在工作流中自动读取环境变量。有关更多信息，请参阅 Maestro 关于 shell 变量的文档。
🌐 Maestro can automatically read environment variables in a workflow when the variable is prefixed by MAESTRO_. For more information, see the Maestro documentation on shell variables.
在运行测试之前生成 Maestro 流
此工作流使用钩子在 Maestro 开始运行测试之前生成 maestro_tests 目录。
🌐 This workflow uses a hook to generate the maestro_tests directory right before Maestro starts running tests.
录制屏幕并使用特定设备
此工作流程在具有特定设备的 Android 模拟器构建上运行 Maestro 测试并记录屏幕。
🌐 This workflow runs Maestro tests on an Android Emulator build with a specific device and records the screen.
保存截图和录制
Maestro 命令例如 takeScreenshot 或 startRecording 会保存你之后可以用于调试的资源。
🌐 Maestro commands such as takeScreenshot or startRecording save assets that you can use for debugging later.
在你的 Maestro 流程文件中，为每个资源指定一个相对路径：
🌐 In your Maestro flow file, give each asset a relative path:
这些资源将可以在“Maestro 测试结果”工件的工件部分中获取。
🌐 The assets will be available within the "Maestro Test Results" artifact in the Artifacts section.
将 Maestro 工件报告到 Slack
此工作流将截图和录制保存到 MAESTRO_TESTS_DIR，然后在测试完成后运行脚本以上传这些文件或将摘要发送到 Slack。
🌐 This workflow saves screenshots and recordings to MAESTRO_TESTS_DIR, then runs a script after the tests finish to upload those files or send a summary to Slack.
Maestro 云
🌐 Maestro Cloud
在 Maestro Cloud 上运行 Maestro 测试。
🌐 Run Maestro tests on Maestro Cloud.
重要 这需要一个 Maestro Cloud 账户和 Cloud 计划订阅。请访问 Maestro 文档 了解更多信息。
语法
🌐 Syntax
jobs: run_maestro_tests: 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 - defaults to `$MAESTRO_CLOUD_API_KEY` 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 - skip validation of the build (whether an iOS build is a simulator build). Defaults to false. 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.
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
重要 你需要在作业环境中设置
maestro_api_key参数或MAESTRO_CLOUD_API_KEY环境变量。请访问 Maestro Cloud 的“设置”来生成 API 密钥，然后到 环境变量 将其添加到你的项目中。
钩子
🌐 Hooks
Maestro Cloud 作业支持以下钩子：
🌐 The following hooks are supported for the Maestro Cloud job:
after_checkout：在工作检查完你的项目后要采取的步骤。before_maestro_cloud：在 Maestro Cloud 上传之前要执行的步骤。after_maestro_cloud：在 Maestro Cloud 上传后要执行的步骤。
有关通用 hooks 语法，请参见 jobs.<job_id>.hooks。
输出
🌐 Outputs
你可以在后续作业中引用以下输出：
🌐 You can reference the following outputs in subsequent jobs:
注意： 使用
async: true模式时，只有maestro_cloud_url输出可以保证有效。其他输出（流程计数和流程名称）可能无效或为空，因为任务不会等待上传完成，并且流程尚未执行。
你还可以使用 jobs.<job_id>.outputs 为此作业定义其他输出。
示例
🌐 Examples
以下是一些使用Maestro Cloud作业的实际示例：
🌐 Here are some practical examples of using the Maestro Cloud job:
基础 Maestro 云测试
此工作流使用默认设置在 iOS 模拟器构建上运行 Maestro 测试。
🌐 This workflow runs Maestro tests on an iOS Simulator build using the default settings.
使用 Maestro 前缀的环境变量
当变量前缀为 MAESTRO_ 时，Maestro 可以在工作流中自动读取环境变量。有关更多信息，请参阅 Maestro 关于 shell 变量的文档。
🌐 Maestro can automatically read environment variables in a workflow when the variable is prefixed by MAESTRO_. For more information, see the Maestro documentation on shell variables.
在后续作业中使用 Maestro Cloud 输出
此工作流运行 Maestro Cloud 测试，然后在 Slack 通知中使用测试结果。
🌐 This workflow runs Maestro Cloud tests and then uses the test results in a Slack notification.
Slack
使用 Slack webhook URL 向 Slack 通道发送消息。
🌐 Send a message to a Slack channel using a Slack webhook URL.
语法
🌐 Syntax
jobs: send_slack_notification: type: slack params: webhook_url: string # required message: string # required if payload is not provided payload: object # required if message is not provided
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
示例
🌐 Examples
以下是一些使用 Slack 职位的实际示例：
🌐 Here are some practical examples of using the Slack job:
基本构建通知
此工作流程构建一个 iOS 应用，然后发送一个包含应用标识符和版本的通知，这些信息来自构建作业的输出。Webhook URL 从作业的 environment 中设置的 SLACK_WEBHOOK_URL 环境变量 中读取。
🌐 This workflow builds an iOS app and then sends a notification with the app identifier and version from the build job outputs. The webhook URL is read from a SLACK_WEBHOOK_URL environment variable set in the job's environment.
使用 Block Kit 的丰富构建通知
此工作流构建一个 Android 应用，并使用构建作业的输出发送富通知。
🌐 This workflow builds an Android app and sends a rich notification using the build job outputs.
GitHub 评论
🌐 GitHub Comment
自动将工作流已完成的构建、更新和部署报告发布到 GitHub 拉取请求中。它特别适用于对 PR 构建提供即时反馈、通过二维码分享测试构建以便轻松在设备上测试、显示 EAS Hosting 部署预览以及自动化部署通知。你还可以通过提供 payload 参数来覆盖评论内容。
🌐 Automatically post reports of your workflow's completed builds, updates, and deployments to GitHub pull requests. It's particularly useful for providing instant feedback on PR builds, sharing test builds with QR codes for easy device testing, displaying EAS Hosting deployment previews, and automating deployment notifications. You can also override the comment contents by providing the payload parameter.
1 要求
1 要求
要使用 GitHub 评论任务，你的项目必须连接一个 GitHub 仓库。了解如何连接你的 GitHub 仓库以开始使用。
语法
🌐 Syntax
jobs: github_comment: 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
参数
🌐 Parameters
该工作以两种互斥的模式运行：
🌐 The job operates in two mutually exclusive modes:
模式1：自动模式（可覆盖）
🌐 Mode 1: Auto-with-overrides mode
默认行为是自动发现构建和更新，如果需要，你可以指定以下任意参数：
🌐 Default behavior is auto discovery builds and updates, you can specify any of these parameters if you want to:
自动发现行为：当未指定（未定义）
build_ids、update_group_ids或deployment_ids时，作业会自动从当前工作流中发现所有相关的构建、更新和部署。要明确排除构建、更新或部署，请传递一个空数组[]。
模式 2：有效载荷模式
🌐 Mode 2: Payload mode
使用有效载荷模式时，你不能指定任何其他参数。
🌐 When using payload mode, you cannot specify any other parameters.
输出
🌐 Outputs
你可以在后续作业中引用以下输出：
🌐 You can reference the following outputs in subsequent jobs:
示例
🌐 Examples
以下是展示 GitHub 评论作业两种模式的实际示例：
🌐 Here are practical examples demonstrating both modes of the GitHub Comment job:
自动覆盖模式示例
🌐 Auto-with-overrides mode examples
自动发现所有构建、更新和部署
这是最简单的用法——自动发现并发布工作流程中的所有构建、更新和部署。
🌐 This is the simplest usage - automatically discovers and posts all builds, updates, and deployments from the workflow.
带自动发现的自定义消息
在仍然自动发现所有构建、更新和部署的同时添加自定义消息。
🌐 Adds a custom message while still auto-discovering all builds, updates, and deployments.
带有 EAS 托管部署的 PR 预览
此工作流使用 EAS 托管部署你网站的预览版本，并将部署详情发布到拉取请求中。
🌐 This workflow deploys a preview of your website using EAS Hosting and posts the deployment details to the pull request.
指定确切的版本和更新
在评论中明确指定要包含的构建和更新。
🌐 Explicitly specify which builds and updates to include in the comment.
排除构建、更新或部署
使用空数组来排除特定的内容类型。
🌐 Use empty arrays to exclude specific content types.
有效载荷模式示例
🌐 Payload mode examples
带有效载荷的完全自定义评论
有效载荷模式让你可以完全控制评论内容。请注意，当使用有效载荷时，你不能指定任何其他参数。
🌐 Payload mode gives you complete control over the comment content. Note that when using payload, you cannot specify any other parameters.
基于构建状态的条件注释
该工作流程会根据构建是成功还是失败发布不同的评论。
🌐 This workflow posts different comments based on whether the build succeeded or failed.
苹果设备注册请求
🌐 Apple device registration request
暂停工作流运行，直到 iOS 设备注册到特定的 Apple 团队 并且团队成员在 expo.dev 上批准该注册。使用这个任务来自动化在 EAS 工作流中为 内部分发 注册设备。
🌐 Pause a workflow run until an iOS device enrolls for a specific Apple team and a team member approves that enrollment on expo.dev. Use this job to automate registering a device for internal distribution inside EAS Workflows.
当工作流到达此作业时，该作业和运行将进入 action-required 并保持暂停状态，直到流程完成：
🌐 When the workflow reaches this job, the job and the run enter action-required and stay paused until the flow completes:
- 工作流运行页面显示用于注册设备的二维码和注册链接。
- 在 iPhone 或 iPad 上，设备会下载配置描述文件并通过“设置”进行安装。每次只有一个配置文件可用，如果在八分钟内未安装，它将被移除。
- 安装后，会收集唯一设备标识符 (UDID) 和元数据。
- 在工作流运行页面上，团队成员可以批准或拒绝注册。批准会将作业标记为成功，并将输出（UDID、型号等）暴露给下游作业。拒绝会导致作业失败，并阻止使用
needs的作业。
如果 UDID 已经在你的账户上注册，该任务仍然需要等待注册和批准后才能继续。
🌐 If the UDID is already registered on your account, the job still waits for enrollment and approval before continuing.
语法
🌐 Syntax
jobs: register_device: type: apple-device-registration-request params: apple_team_identifier: string # optional
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
输出
🌐 Outputs
在团队成员批准已注册设备后，你可以在后续作业中参考以下输出内容：
🌐 After a team member approves the enrolled device, you can reference the following outputs in subsequent jobs:
如果团队成员拒绝加入，则作业失败且不会设置输出。使用 needs 的下游作业将不会运行。
🌐 If a team member rejects the enrollment, the job fails and does not set outputs. Downstream jobs that use needs will not run.
示例
🌐 Examples
以下是使用 Apple 设备注册请求任务的一些实际示例：
🌐 Here are some practical examples of using the Apple device registration request job:
注册设备并通知 Slack
此工作流程注册一个 iOS 设备，并通过 Slack 发送包含作业输出中的设备 UDID 和型号的消息。
🌐 This workflow registers an iOS device and sends a Slack message with the device UDID and model from the job outputs.
注册设备，然后运行内部 iOS 构建
此工作流程会注册设备，然后运行 iOS 内部分发构建，以刷新临时配置文件，使新设备被包含在内。
🌐 This workflow registers a device and then runs an iOS internal distribution build that refreshes the ad hoc provisioning profile so the new device is included.
preview 配置文件必须设置 distribution: internal 并使用 由 EAS 管理的凭据。对于 CI，你还需要一个 App Store Connect API 密钥。参见 CI 上的内部分发 和 从 CI 触发构建。
🌐 The preview profile must set distribution: internal and use credentials managed by EAS. For CI, you also need an App Store Connect API key. See internal distribution on CI and trigger builds from CI.
需要批准
🌐 Require Approval
在继续工作流程之前，需要用户的批准。用户可以批准或拒绝，这将对应任务的成功或失败。
🌐 Require approval from a user before continuing with the workflow. A user can approve or reject which translates to success or failure of the job.
语法
🌐 Syntax
jobs: require_approval: type: require-approval
参数
🌐 Parameters
这个任务不需要任何参数。
🌐 This job doesn't take any parameters.
示例
🌐 Examples
以下是使用“需要批准”任务的一些实际示例：
🌐 Here are some practical examples of using the Require Approval job:
在部署到生产环境之前请求批准
此工作流将 Web 应用部署到预览环境，然后在部署到生产环境之前需要用户批准。
🌐 This workflow deploys a web app to preview and then requires approval from a user before deploying to production.
工作流的控制流
此工作流程允许用户在揭示结局之前，通过要求批准来决定故事如何结束。
🌐 This workflow lets a user decide how the story ends by requiring approval before revealing the conclusion.
文档
🌐 Doc
在工作流日志中显示 Markdown 部分。
🌐 Displays a Markdown section in the workflow logs.
语法
🌐 Syntax
jobs: show_whats_next: type: doc params: md: string
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
示例
🌐 Examples
以下是一些使用文档工作的实际例子：
🌐 Here are some practical examples of using the Doc job:
显示说明
此工作流程会构建一个 iOS 应用，然后在工作流程日志中显示一个 Markdown 部分。
🌐 This workflow builds an iOS app and then displays a Markdown section in the workflow logs.
重新打包
🌐 Repack
从现有构建中重新打包应用。此任务会重新打包应用的元数据和 JavaScript 包，而无需执行完整的原生重建，这对于创建与特定指纹兼容的更快速构建非常有用。
🌐 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.
语法
🌐 Syntax
jobs: repack: type: repack runs_on: string # optional - see https://expo.nodejs.cn/build-reference/infrastructure/ for available options 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 - steps to run after the job checks out your project. before_install_node_modules: step[] # optional - steps to run before the job installs dependencies. after_install_node_modules: step[] # optional - steps to run after the job installs dependencies.
注意： 如果构建可能仍在进行中，请使用
get-build和wait_for_in_progress: true，然后将其build_id传递给repack。
常见问题
🌐 Common questions
什么时候使用 repack，什么时候不使用？
重新封装工作适用于以下情况：
🌐 Repack job is suitable for the following use cases:
- 通过重用现有构建来减少 CI 构建时间
- 在需要时触发完整的本地构建
- 为你的团队提供更快速的反馈循环
重新封装工作不适用于以下情况：
🌐 Repack job is not suitable for the following use cases:
- 生产版本需要通过完整的构建流程以确保符号化和应用签名正确
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中：
🌐 You can pass the following parameters into the params list:
钩子
🌐 Hooks
Repack 任务支持以下钩子：
🌐 The following hooks are supported for the Repack job:
after_checkout：在工作检查完你的项目后要采取的步骤。before_install_node_modules：在工作安装你项目的依赖之前要运行的步骤。after_install_node_modules：在作业安装完你项目的依赖后要执行的步骤。
有关通用 hooks 语法，请参见 jobs.<job_id>.hooks。
示例
🌐 Examples
以下是使用指纹与重打包任务的一些实际示例：
🌐 Here are some practical examples of using the Fingerprint with Repack jobs:
使用 Fingerprint 和 Repack 的持续部署
此工作流程首先生成指纹，然后根据是否已存在与该指纹兼容的构建来构建或重新打包应用。最后，它运行 Maestro 测试。
🌐 This workflow first generates a fingerprint and then builds or repacks the app depending on whether a compatible build for that fingerprint already exists. Finally, it runs Maestro tests.