EAS 工作流中的预打包任务
了解如何在 EAS 工作流中设置和使用预打包的作业。
For the complete documentation index, see llms.txt. Use this file to discover all available pages.
预封装作业是现成可用的工作流作业,可帮助你自动执行常见任务,例如构建、提交和测试应用。它们提供了一种标准化的方法来处理这些操作,而无需从头编写自定义作业配置。本指南介绍了可用的预封装作业以及如何在工作流中使用它们。
🌐 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 requirement
1 requirement
使用与预打包作业相同的平台和配置文件,通过 EAS CLI 完成构建。了解如何创建你的第一个构建以开始使用。
语法
🌐 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
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中:
🌐 You can pass the following parameters into the params list:
| 参数 | 类型 | 描述 |
|---|---|---|
| platform | string | 必填。 要构建的平台。可以是 android 或 ios。 |
| profile | string | 可选。要使用的构建配置文件。默认为 production。 |
| message | string | 可选。附加到构建的自定义消息。在运行 eas build 时对应于 --message 标志。 |
环境变量
🌐 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:
| 输出 | 类型 | 描述 |
|---|---|---|
| build_id | 字符串 | 创建的构建的ID。 |
| app_build_version | 字符串 | 应用的版本代码/构建号。 |
| app_identifier | 字符串 | 应用的包标识符/包名。 |
| app_version | 字符串 | 应用的版本。 |
| channel | 字符串 | 构建使用的更新渠道。 |
| distribution | 字符串 | 使用的分发方式。可以是 internal 或 store。 |
| fingerprint_hash | 字符串 | 构建的指纹哈希。 |
| git_commit_hash | 字符串 | 用于构建的 git 提交哈希。 |
| platform | 字符串 | 创建构建的平台。可以是 android 或 ios。 |
| profile | 字符串 | 使用的构建配置文件。 |
| runtime_version | 字符串 | 使用的运行时版本。 |
| sdk_version | 字符串 | 使用的 SDK 版本。 |
| simulator | 字符串 | 构建是否用于模拟器。 |
示例
🌐 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.
name: Build iOS app on: push: branches: ['main'] jobs: build_ios: name: Build iOS type: build params: platform: ios profile: production
同时为两个平台构建
当你推送到主分支时,此工作流会同时构建 Android 和 iOS 应用。
🌐 This workflow builds both Android and iOS apps in parallel when you push to the main branch.
name: Build for all platforms on: push: branches: ['main'] jobs: build_android: name: Build Android type: build params: platform: android profile: production build_ios: name: Build iOS type: build params: platform: ios profile: production
使用环境变量构建
此工作流程使用自定义环境变量构建你的 Android 应用,这些变量可以在构建过程中使用。
🌐 This workflow builds your Android app with custom environment variables that can be used during the build process.
name: Build with environment variables on: push: branches: ['main'] jobs: build_android: name: Build Android type: build env: APP_ENV: production API_URL: https://api.example.com params: platform: android profile: production
使用不同的配置构建
此工作流使用不同的配置创建两个不同的 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.
name: Build with different profiles on: push: branches: ['main'] jobs: build_android_development: name: Build Android Development type: build params: platform: android profile: development build_android_production: name: Build Android Production type: build params: platform: android profile: production
部署
🌐 Deploy
使用 EAS Hosting 部署你的应用。
🌐 Deploy your application using EAS Hosting.
1 requirement
1 requirement
有关设置说明,请参阅 开始使用 EAS 托管
语法
🌐 Syntax
jobs: deploy_web: type: deploy params: alias: string # optional prod: boolean # optional
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中:
🌐 You can pass the following parameters into the params list:
| 参数 | 类型 | 描述 |
|---|---|---|
| alias | 字符串 | 可选。要部署到的 别名。 |
| prod | 布尔值 | 可选。是否部署到生产环境。 |
输出
🌐 Outputs
你可以在后续作业中引用以下输出:
🌐 You can reference the following outputs in subsequent jobs:
| 输出 | 类型 | 描述 |
|---|---|---|
| deploy_json | 字符串 | 包含部署详细信息的 JSON 对象(npx eas-cli deploy --json 的输出)。 |
| deploy_url | 字符串 | 部署的 URL。如果这是生产部署,则使用生产 URL。否则,使用第一个别名 URL 或部署 URL。 |
| deploy_alias_url | 字符串 | 部署的别名 URL(例如,https://account-project--alias.expo.app)。 |
| deploy_deployment_url | 字符串 | 部署的唯一 URL(例如,https://account-project--uniqueid.expo.app)。 |
| deploy_identifier | 字符串 | 部署的标识符。 |
| deploy_dashboard_url | 字符串 | 部署控制面板的 URL(例如,https://expo.dev/projects/[project]/hosting/deployments)。 |
示例
🌐 Examples
以下是一些使用部署任务的实际示例:
🌐 Here are some practical examples of using the deploy job:
基本部署到生产环境
此工作流程使用 EAS Hosting 将你的应用部署到生产环境。
🌐 This workflow deploys your application to production using EAS Hosting.
name: Basic Deployment jobs: deploy: name: Deploy to Production type: deploy params: prod: true
仅在合并到 `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.
name: Deploy on: push: branches: ['*'] jobs: deploy: name: Deploy type: deploy params: prod: ${{ github.ref_name == 'main' }}
使用自定义别名的部署
此工作流程将你的应用部署到生产环境中的自定义别名。
🌐 This workflow deploys your application to a custom alias in production.
name: Deployment with Alias jobs: deploy: name: Deploy with Alias type: deploy params: alias: my-custom-alias prod: true
指纹
🌐 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
环境变量
🌐 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:
| 参数 | 类型 | 描述 |
|---|---|---|
| unstable_skip_cng_check | 布尔值 | 可选。是否跳过对连续原生生成(CNG)兼容性的检查。默认值为 false。 |
输出
🌐 Outputs
你可以在后续作业中引用以下输出:
🌐 You can reference the following outputs in subsequent jobs:
| 输出 | 类型 | 描述 |
|---|---|---|
| android_fingerprint_hash | 字符串 | Android 的指纹哈希。 |
| ios_fingerprint_hash | 字符串 | iOS 的指纹哈希。 |
示例
🌐 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.
name: Basic Fingerprint jobs: fingerprint: name: Calculate Fingerprint type: fingerprint environment: production
带内联环境变量的指纹
注意: 如果你依赖内联环境变量,你需要确保在每个地方(构建配置文件、指纹任务、更新任务等)都将正确的环境变量设置为正确的值,以使指纹匹配。我们建议使用EAS 环境变量,你可以在其中将一组变量分组到环境中,并在构建配置文件和工作流任务中引用它们。
name: Fingerprint with Environment Variables jobs: fingerprint: name: Calculate Fingerprint type: fingerprint environment: production # Resulting environment will be a union of the "production" environment and the inline environment variables. # `env` variables override environment variables of the same name from the "production" environment. env: APP_VARIANT: staging API_URL: https://api.staging.example.com
获取构建
🌐 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:
| 参数 | 类型 | 描述 |
|---|---|---|
| platform | string | 可选。要获取构建的目标平台。可以是 ios 或 android。 |
| profile | string | 可选。要使用的构建配置文件。 |
| distribution | string | 可选。分发方式。可以是 store、internal 或 simulator。 |
| channel | string | 可选。更新通道。 |
| app_identifier | string | 可选。应用的 bundle 标识符/包名。 |
| app_build_version | string | 可选。构建版本。 |
| app_version | string | 可选。应用版本。 |
| git_commit_hash | string | 可选。Git 提交哈希值。 |
| fingerprint_hash | string | 可选。指纹哈希值。 |
| sdk_version | string | 可选。SDK 版本。 |
| runtime_version | string | 可选。运行时版本。 |
| simulator | boolean | 可选。是否获取模拟器构建。 |
| wait_for_in_progress | boolean | 可选。是否等待匹配的进行中构建。默认值:false。 |
如果将 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:
| 输出 | 类型 | 描述 |
|---|---|---|
| build_id | 字符串 | 检索到的构建 ID。 |
| app_build_version | 字符串 | 应用的构建版本。 |
| app_identifier | 字符串 | 应用的包标识符/包名。 |
| app_version | 字符串 | 应用的版本。 |
| channel | 字符串 | 构建使用的更新渠道。 |
| distribution | 字符串 | 使用的分发方式。 |
| fingerprint_hash | 字符串 | 构建的指纹哈希值。 |
| git_commit_hash | 字符串 | 构建使用的 Git 提交哈希值。 |
| platform | 字符串 | 构建针对的平台。 |
| profile | 字符串 | 使用的构建配置文件。 |
| runtime_version | 字符串 | 使用的运行时版本。 |
| sdk_version | 字符串 | 使用的 SDK 版本。 |
| simulator | 字符串 | 构建是否用于模拟器。 |
示例
🌐 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.
name: Get Production Build jobs: get_build: name: Get Latest Production Build type: get-build params: platform: ios profile: production distribution: store channel: production
按版本构建
此工作流程通过应用版本和构建版本检索特定版本的 Android 构建。
🌐 This workflow retrieves a specific version of an Android build by its app version and build version.
name: Get Build by Version jobs: get_build: name: Get Specific Version Build type: get-build params: platform: android app_identifier: com.example.app app_version: 1.0.0 app_build_version: 42
获取模拟器构建
此工作流程用于获取 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.
name: Get Simulator Build jobs: get_build: name: Get Simulator Build type: get-build params: platform: ios simulator: true profile: development wait_for_in_progress: true
提交
🌐 Submit
使用 EAS Submit 将 Android 或 iOS 版本提交到应用商店。
🌐 Submit an Android or iOS build to the app store using EAS Submit.
1 requirement
1 requirement
提交作业需要额外的配置才能在 CI/CD 流程中运行。有关更多信息,请参阅 Google Play 商店 CI/CD 提交指南 和 Apple App Store CI/CD 提交指南。
语法
🌐 Syntax
jobs: submit_to_store: type: submit runs_on: string # optional - see https://expo.nodejs.cn/build-reference/infrastructure/ for available options params: build_id: string # required profile: string # optional - default: production
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中:
🌐 You can pass the following parameters into the params list:
| 参数 | 类型 | 描述 |
|---|---|---|
| build_id | 字符串 | 必填。要提交的构建的ID。 |
| profile | 字符串 | 可选。要使用的提交配置文件。默认为 production。 |
输出
🌐 Outputs
你可以在后续作业中引用以下输出:
🌐 You can reference the following outputs in subsequent jobs:
| 输出 | 类型 | 描述 |
|---|---|---|
| apple_app_id | 字符串 | 提交的构建的 Apple 应用 ID。 |
| ios_bundle_identifier | 字符串 | 提交的构建的 iOS 包标识符。 |
| android_package_id | 字符串 | 提交的构建的 Android 包 ID。 |
示例
🌐 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.
name: Submit iOS Build jobs: build_ios: name: Build iOS type: build params: platform: ios profile: production submit: name: Submit to App Store type: submit needs: [build_ios] params: build_id: ${{ needs.build_ios.outputs.build_id }} profile: production
提交 Android 构建
此工作流程使用生产提交配置将 Android 构建提交到 Play 商店。
🌐 This workflow submits an Android build to the Play Store using the production submit profile.
name: Submit Android Build jobs: build_android: name: Build Android type: build params: platform: android profile: production submit: name: Submit to Play Store type: submit needs: [build_android] params: build_id: ${{ needs.build_android.outputs.build_id }} profile: production
TestFlight
将 iOS 构建分发到 TestFlight 的内部和外部测试组。这是 iOS 提交作业的替代方案,当你需要更高级的 TestFlight 功能时使用。如果你需要控制测试组、更新日志或测试版应用审核提交,请使用 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.
1 requirement
1 requirement
TestFlight 任务需要使用 distribution: store 创建的 iOS 构建以及已配置的 Apple 开发者账户。有关更多信息,请参阅 TestFlight 提交指南。
语法
🌐 Syntax
jobs: testflight_distribution: type: testflight runs_on: string # optional - see https://expo.nodejs.cn/build-reference/infrastructure/ for available options 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)
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中:
🌐 You can pass the following parameters into the params list:
| 参数 | 类型 | 描述 |
|---|---|---|
| build_id | string | 必填。要分发的 iOS 构建的 ID。 |
| profile | string | 可选。要使用的提交配置文件。默认为 production。 |
| internal_groups | string[] | 可选。要将构建添加到的 TestFlight 内部组名称数组。仅包括未启用自动分发的组。 |
| external_groups | string[] | 可选。要将构建添加到的 TestFlight 外部组名称数组。 |
| changelog | string | 可选。TestFlight 测试者的测试说明(“测试内容”)。 |
| submit_beta_review | boolean | 可选。是否提交 Beta 应用审核。如果未指定,当提供 external_groups 时默认为 true,否则为 false。 |
| wait_processing_timeout_seconds | number | 可选。等待 App Store Connect 构建处理的超时时间(秒)。默认为 1800(30 分钟)。 |
输出
🌐 Outputs
你可以在后续作业中引用以下输出:
🌐 You can reference the following outputs in subsequent jobs:
| 输出 | 类型 | 描述 |
|---|---|---|
| apple_app_id | 字符串 | 提交的构建的 Apple 应用 ID |
| ios_bundle_identifier | 字符串 | 提交的构建的 iOS 包标识符 |
示例
🌐 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.
name: TestFlight Distribution jobs: build_ios: name: Build iOS type: build params: platform: ios profile: production testflight: name: Distribute to TestFlight type: testflight needs: [build_ios] params: build_id: ${{ needs.build_ios.outputs.build_id }} internal_groups: ['QA Team'] external_groups: ['Public Beta'] changelog: | What's new in this release: - New features - Bug fixes
仅上传更新日志
这个工作流程会上传一个带有更改日志的构建,但不会指定任何明确要添加构建的组。该构建只会被添加到启用了“自动分发”的内部组中。
🌐 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.
name: TestFlight with Changelog jobs: testflight: name: Upload with Changelog type: testflight params: build_id: ${{ needs.build_ios.outputs.build_id }} changelog: "${{ github.commit_message || 'Bug fixes' }}" # github.commit_message only available in push & schedule events.
更新
🌐 Update
使用 EAS Update 发布更新。
🌐 Publish an update using EAS Update.
1 requirement
1 requirement
用于发布更新预览和发送空中更新。运行 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 runs_on: string # optional - see https://expo.nodejs.cn/build-reference/infrastructure/ for available options params: message: string # optional platform: string # optional - android | ios | all, defaults to all branch: string # optional channel: string # optional - cannot be used with branch private_key_path: string # optional upload_sentry_sourcemaps: boolean # optional - defaults to "try uploading, but don't fail the job if it fails"
环境变量
🌐 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:
| 参数 | 类型 | 描述 |
|---|---|---|
| 信息 | 字符串 | 可选。用于更新的信息。如果未提供,将使用提交信息。 |
| 平台 | 字符串 | 可选。用于更新的平台。可以是 android、ios 或 all。默认值为 all。 |
| 分支 | 字符串 | 可选。用于更新的分支。如果未提供,将使用工作流运行中的分支。对于手动运行的工作流,你需要提供一个值。示例:${{ github.ref_name || 'testing' }}。请只提供分支或通道中的一个,而不是两者。 |
| 通道 | 字符串 | 可选。用于更新的通道。提供分支或通道中的_任意一个_,不能同时提供两者。 |
| private_key_path | 字符串 | 可选。包含与 EAS 更新配置 中证书对应的 PEM 编码私钥的文件路径。你可以使用 "$VARIABLE_NAME" 语法引用文件类型的 EAS 环境变量。这等同于向 EAS CLI 传递 --private-key-path。 |
| upload_sentry_sourcemaps | 布尔值 | 可选。是否上传 Sentry 源映射。如果值为 true,任务将上传 Sentry 源映射,并且上传失败时任务会失败。如果值为 false,任务将不会向 Sentry 上传源映射。如果未提供该值,任务将检查是否安装了 @sentry/react-native,如果安装了,则尝试上传源映射。如果上传失败,它只会打印错误信息,并继续将任务标记为成功。 |
输出
🌐 Outputs
你可以在后续作业中引用以下输出:
🌐 You can reference the following outputs in subsequent jobs:
| 输出 | 类型 | 描述 |
|---|---|---|
| first_update_group_id | 字符串 | 第一个更新组的ID。 |
| updates_json | 字符串 | 包含所有更新组信息的JSON字符串。 |
示例
🌐 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.
name: Update Production on: push: branches: ['main'] jobs: update_production: name: Update Production Channel type: update params: channel: production
特定平台的更新
此工作流程为 Android 和 iOS 平台发布单独的更新,允许进行特定于平台的更改。
🌐 This workflow publishes separate updates for Android and iOS platforms, allowing for platform-specific changes.
name: Platform-specific Updates on: push: branches: ['main'] jobs: update_android: name: Update Android type: update params: platform: android channel: production update_ios: name: Update iOS type: update params: platform: ios channel: production
使用基于分支的部署进行更新
此工作流程会根据分支名称发布更新,从而根据分支区分不同的环境(测试/生产)。
🌐 This workflow publishes updates based on the branch name, allowing for different environments (staging/production) based on the branch.
name: Branch-based Updates on: push: branches: ['main', 'staging'] jobs: update_branch: name: Update Branch type: update params: branch: ${{ github.ref_name }} message: 'Update for branch: ${{ github.ref_name }}'
大师
🌐 Maestro
在 Android 模拟器或 iOS 模拟器构建上运行 Maestro 测试。
🌐 Run Maestro tests on a 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. 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
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中:
🌐 You can pass the following parameters into the params list:
| 参数 | 类型 | 描述 |
|---|---|---|
| build_id | 字符串 | 必填。要测试的构建的ID。 |
| flow_path | 字符串 或 字符串数组 | 必填。要运行的 Maestro 流程文件或目录的路径。 |
| 分片 | 数量 | 可选且实验性。要将测试拆分成的分片数量。默认值为 1。 |
| 重试次数 | 数字 | 可选。如果测试失败,则重试的次数。默认为 0。 |
| retry_failed_only | 布尔值 | 可选。当为 true(默认值)时,重试将尝试仅重新运行上一次尝试中失败的流程(如适用)。设置为 false 则每次重试都会重新运行所有流程。 |
| record_screen | 布尔值 | 可选。是否录制屏幕。默认值为 false。注意:录制屏幕可能影响模拟器性能。录制屏幕时,你可能需要使用大型运行器。 |
| include_tags | 字符串或字符串数组 | 可选。在测试中要包含的流程标签。将作为 --include-tags 传递给 Maestro。 |
| exclude_tags | 字符串或字符串数组 | 可选。要从测试中排除的流程标签。将作为 --exclude-tags 传递给 Maestro。 |
| maestro_version | 字符串 | 可选。用于测试的 Maestro 版本。如果未提供,将使用最新版本。 |
| output_format | 字符串 | 可选。Maestro 测试报告格式。默认为 junit。将作为 --format 传递给 Maestro。可以是 junit 或其他支持的格式。 |
| android_system_image_package | 字符串 | 可选。要使用的 Android 模拟器系统镜像包。在你的机器上运行 sdkmanager --list 列出可用的包。选择一个 x86_64 变体。示例:system-images;android-36;google_apis;x86_64,system-images;android-35-ext15;google_apis_playstore;x86_64。请注意,较新的镜像需要更多的计算资源,因此你可能需要使用大规范的运行器。 |
| 设备标识符 | 字符串或 { android?: string, ios?: string } 对象 | 可选。用于测试的设备标识符。你也可以使用单值表达式,如 pixel_6、iPhone 16 Plus 或 ${{ needs.build.outputs.platform == "android" ? "pixel_6" : "iPhone 16 Plus" }},以及像 device_identifier: { android: "pixel_6", ios: "iPhone 16 Plus" } 这样的对象。请注意,iOS 设备的可用性因运行器镜像而异。可用设备列表可在作业日志中找到。 |
| skip_build_check | 布尔值 | 可选。跳过对构建的验证(例如 iOS 构建是否为模拟器构建)。默认值为 false。 |
示例
🌐 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.
name: Basic Maestro Test jobs: test: name: Run Maestro Tests type: maestro environment: preview params: build_id: ${{ needs.build_ios_simulator.outputs.build_id }} flow_path: ./maestro/flows
Maestro 分片测试
此工作流在 Android 模拟器上运行 Maestro 测试,使用 3 个分片,并对失败的测试进行 2 次重试。
🌐 This workflow runs Maestro tests on an Android emulator build with 3 shards and 2 retries for failed tests.
name: Sharded Maestro Test jobs: test: name: Run Sharded Maestro Tests type: maestro environment: preview runs_on: linux-large-nested-virtualization params: build_id: ${{ needs.build_android_emulator.outputs.build_id }} flow_path: ./maestro/flows shards: 3 retries: 2
使用 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.
name: Basic Maestro Test jobs: test: name: Run Maestro Tests type: maestro env: MAESTRO_APP_ID: 'com.yourhost.yourapp' params: build_id: ${{ needs.build_ios_simulator.outputs.build_id }}
录制屏幕并使用特定设备
此工作流程在使用特定设备构建的 Android 模拟器上运行 Maestro 测试并录制屏幕。
🌐 This workflow runs Maestro tests on an Android emulator build with a specific device and records the screen.
name: Pixel E2E Test jobs: test: name: Run Maestro Tests type: maestro runs_on: linux-large-nested-virtualization params: build_id: ${{ needs.build_android_emulator.outputs.build_id }} device_identifier: 'pixel_6' record_screen: true android_system_image_package: 'system-images;android-35;default;x86_64'
保存截图和录制
要保存由 Maestro 命令(例如 takeScreenshot 或 startRecording)创建的资源以便稍后用于调试,请使用 MAESTRO_TESTS_DIR 环境变量。
🌐 To save assets created by Maestro commands (such as takeScreenshot or startRecording) to use for debugging later, use the MAESTRO_TESTS_DIR environment variable.
在你的 Maestro 流程文件中,指定资源位置:
🌐 In your Maestro flow file, specify the asset locations:
appId: com.myapp --- - launchApp - startRecording: ${MAESTRO_TESTS_DIR}/my_recording - takeScreenshot: ${MAESTRO_TESTS_DIR}/my_screenshot - tapOn: 'Login Button' - takeScreenshot: ${MAESTRO_TESTS_DIR}/after_login_screenshot - stopRecording
这些资源将可以在“Maestro 测试结果”工件的工件部分中获取。
🌐 The assets will be available within the "Maestro Test Results" artifact in the Artifacts section.
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. 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`.
参数
🌐 Parameters
你可以将以下参数传递到 params 列表中:
🌐 You can pass the following parameters into the params list:
| 参数 | 类型 | 描述 |
|---|---|---|
| build_id | 字符串 | 必填。要测试的构建 ID。例如:${{ needs.build_android.outputs.build_id }}。 |
| maestro_project_id | 字符串 | 必填。要使用的 Maestro Cloud 项目的 ID。对应于 maestro cloud 的 --project-id 参数。示例:proj_01jw6hxgmdffrbye9fqn0pyzm0。前往 Maestro Cloud 查找你的项目 ID。 |
| flows | 字符串 | 必填。Maestro 流程文件或包含要运行的流程的目录的路径。对应于 maestro cloud 的 --flows 参数。 |
| maestro_api_key | 字符串 | 可选。用于Maestro项目的API密钥。默认情况下,将使用 MAESTRO_CLOUD_API_KEY 环境变量。对应 maestro cloud 的 --api-key 参数。 |
| include_tags | 字符串 | 可选。在测试中要包含的标签。对应于 maestro cloud 的 --include-tags 参数。示例:"pull,push"。 |
| exclude_tags | 字符串 | 可选。要从测试中排除的标签。对应于 maestro cloud 的 --exclude-tags 参数。示例:"disabled"。 |
| maestro_version | 字符串 | 可选。要使用的 Maestro 版本。例如:1.30.0。 |
| maestro_config | 字符串 | 可选。要使用的 Maestro config.yaml 文件的路径。对应于 maestro cloud 的 --config 参数。例如:.maestro/config.yaml。 |
| device_locale | 字符串 | 可选。在用于测试的设备上将设置的区域设置。对应于 maestro cloud 的 --device-locale 参数。示例:pl_PL。 |
| device_model | 字符串 | 可选。用于测试的设备型号。对应于 maestro cloud 的 --device-model 参数。示例:iPhone-11。运行 maestro list-cloud-devices 获取支持的值列表。 |
| device_os | 字符串 | 可选。用于测试的设备操作系统。对应 --device-os 参数的 maestro cloud。示例:iOS-18-2。运行 maestro list-cloud-devices 获取支持的值列表。 |
| 名称 | 字符串 | 可选。Maestro 云上传的名称。对应 maestro cloud 的 --name 参数。 |
| 分支 | 字符串 | 可选。用于覆盖 Maestro Cloud 上传来源的分支。默认情况下,如果工作流运行是由 GitHub 触发的,将使用该工作流运行的分支。对应于 maestro cloud 的 --branch 参数。 |
| async | 布尔值 | 可选。异步运行 Maestro Cloud 测试。如果为 true,作业的状态只表示上传是否成功,而不表示测试是否成功。对应 maestro cloud 的 --async 参数。 |
重要 你需要在作业环境中设置
maestro_api_key参数或MAESTRO_CLOUD_API_KEY环境变量。请访问 Maestro Cloud 的“设置”来生成 API 密钥,然后到 环境变量 将其添加到你的项目中。
输出
🌐 Outputs
你可以在后续作业中引用以下输出:
🌐 You can reference the following outputs in subsequent jobs:
| 输出 | 类型 | 描述 |
|---|---|---|
| maestro_cloud_url | 字符串 | Maestro Cloud 上传结果页面的 URL。 |
| total_flows_count | 数字 | 执行的流程总数。 |
| successful_flows_count | 数字 | 成功完成的流程数量(状态为 SUCCESS 或 WARNING)。 |
| failed_flows_count | 数字 | 失败的流程数量(状态为 ERROR 或 STOPPED)。 |
| successful_flow_names_json | 字符串 | 包含成功流程名称的 JSON 数组。 |
| failed_flow_names_json | 字符串 | 包含失败流程名称的 JSON 数组。 |
注意: 使用
async: true模式时,只有maestro_cloud_url输出可以保证有效。其他输出(流程计数和流程名称)可能无效或为空,因为任务不会等待上传完成,并且流程尚未执行。
示例
🌐 Examples
以下是一些使用 Maestro 任务的实际示例:
🌐 Here are some practical examples of using the Maestro job:
基础 Maestro 云测试
此工作流使用默认设置在 iOS 模拟器构建上运行 Maestro 测试。
🌐 This workflow runs Maestro tests on an iOS Simulator build using the default settings.
name: Basic Maestro Test jobs: test: name: Run Maestro Tests type: maestro-cloud environment: preview params: build_id: ${{ needs.build_ios_simulator.outputs.build_id }} maestro_project_id: proj_01jw6hxgmdffrbye9fqn0pyzm0 flows: ./maestro/flows
使用 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.
name: Basic Maestro Test jobs: test: name: Run Maestro Tests type: maestro-cloud env: MAESTRO_APP_ID: 'com.yourhost.yourapp' params: build_id: ${{ needs.build_ios_simulator.outputs.build_id }} maestro_project_id: proj_01jw6hxgmdffrbye9fqn0pyzm0 flows: ./maestro/flows
在后续作业中使用 Maestro Cloud 输出
此工作流运行 Maestro Cloud 测试,然后在 Slack 通知中使用测试结果。
🌐 This workflow runs Maestro Cloud tests and then uses the test results in a Slack notification.
name: Maestro Cloud with Notification jobs: maestro_test: name: Run Maestro Cloud Tests type: maestro-cloud environment: preview params: build_id: ${{ needs.build.outputs.build_id }} maestro_project_id: proj_xyz flows: ./maestro/flows notify: name: Send Test Results after: [maestro_test] type: slack environment: production params: webhook_url: ${{ env.SLACK_WEBHOOK_URL }} # make sure to set it up in the right environment (see "environment: ..." above) message: 'Tests complete: ${{ after.maestro_test.outputs.successful_flows_count }}/${{ after.maestro_test.outputs.total_flows_count }} passed'
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:
| 参数 | 类型 | 描述 |
|---|---|---|
| webhook_url | string | 必填。发送消息的 Slack webhook URL。目前仅支持硬编码字符串。使用存储在 env 的 webhook 功能即将推出,但尚不支持。 |
| message | string | 如果未提供 payload,则必填。要发送的消息。 |
| payload | object | 如果未提供 message,则必填。要发送的 Slack Block Kit payload。 |
示例
🌐 Examples
以下是一些使用 Slack 职位的实际示例:
🌐 Here are some practical examples of using the Slack job:
基本构建通知
该工作流程会构建一个 iOS 应用,然后发送一条通知,内容包括构建任务输出的应用标识符和版本。
🌐 This workflow builds an iOS app and then sends a notification with the app identifier and version from the build job outputs.
name: Build Notification jobs: build_ios: name: Build iOS type: build params: platform: ios profile: production notify_build: name: Notify Build Status needs: [build_ios] type: slack params: webhook_url: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX message: 'Build completed for app ${{ needs.build_ios.outputs.app_identifier }} (version ${{ needs.build_ios.outputs.app_version }})'
使用 Block Kit 的丰富构建通知
此工作流构建一个 Android 应用,并使用构建作业的输出发送富通知。
🌐 This workflow builds an Android app and sends a rich notification using the build job outputs.
name: Rich Build Notification jobs: build_android: name: Build Android type: build params: platform: android profile: production notify_build: name: Notify Build Status needs: [build_android] type: slack params: webhook_url: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX payload: blocks: - type: header text: type: plain_text text: 'Build Completed' - type: section fields: - type: mrkdwn text: "*App:*\n${{ needs.build_android.outputs.app_identifier }}" - type: mrkdwn text: "*Version:*\n${{ needs.build_android.outputs.app_version }}" - type: section fields: - type: mrkdwn text: "*Build ID:*\n${{ needs.build_android.outputs.build_id }}" - type: mrkdwn text: "*Platform:*\n${{ needs.build_android.outputs.platform }}" - type: section text: type: mrkdwn text: 'Distribution: ${{ needs.build_android.outputs.distribution }}'
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 requirement
1 requirement
要使用 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:
| 参数 | 类型 | 描述 |
|---|---|---|
| message | string | 可选。在评论顶部包含的自定义消息。默认为“你的构建、更新和部署已准备好进行测试!” |
| build_ids | string[] | 可选。要包含的特定构建 ID 数组。如果未指定,则会自动发现所有已完成/失败/取消的构建。使用空数组 [] 排除构建。 |
| update_group_ids | string[] | 可选。要包含的特定更新组 ID 数组。如果未指定,则会自动发现所有成功的更新。使用空数组 [] 排除更新。 |
| deployment_ids | string[] | 可选。要包含的特定部署 ID 数组。如果未指定,则会自动发现所有成功的部署。使用空数组 [] 排除部署。 |
自动发现行为:当未指定(未定义)
build_ids、update_group_ids或deployment_ids时,作业会自动从当前工作流中发现所有相关的构建、更新和部署。要明确排除构建、更新或部署,请传递一个空数组[]。
模式 2:有效载荷模式
🌐 Mode 2: Payload mode
使用有效载荷模式时,你不能指定任何其他参数。
🌐 When using payload mode, you cannot specify any other parameters.
| 参数 | 类型 | 描述 |
|---|---|---|
| payload | string | 要作为评论发布的原始 markdown 或 HTML 内容。支持工作流变量插值。 |
输出
🌐 Outputs
你可以在后续作业中引用以下输出:
🌐 You can reference the following outputs in subsequent jobs:
| 输出 | 类型 | 描述 |
|---|---|---|
| comment_url | 字符串 | 已发布的 GitHub 评论的 URL(仅在评论成功发布时可用)。 |
示例
🌐 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.
name: PR Auto Comment on: pull_request: {} jobs: # ... comment_on_pr: name: Post Results to PR after: [build_ios, build_android, publish_update, deploy] type: github-comment # No params needed - auto-discovers all builds, updates, and deployments
带自动发现的自定义消息
在仍然自动发现所有构建、更新和部署的同时添加自定义消息。
🌐 Adds a custom message while still auto-discovering all builds, updates, and deployments.
name: PR Custom Message on: pull_request: {} jobs: # ... comment_on_pr: name: Post Build to PR after: [build_ios, build_android, publish_update, deploy] type: github-comment params: message: '🎉 Preview builds are ready! Please test these changes before approving the PR.' # build_ids, update_group_ids, and deployment_ids are undefined, so auto-discovery is enabled
带有 EAS 托管部署的 PR 预览
此工作流使用 EAS 托管部署你网站的预览版本,并将部署详情发布到拉取请求中。
🌐 This workflow deploys a preview of your website using EAS Hosting and posts the deployment details to the pull request.
name: PR Preview on: pull_request: {} jobs: deploy: type: deploy name: Deploy PR Preview comment: needs: [deploy] type: github-comment
指定确切的版本和更新
在评论中明确指定要包含的构建和更新。
🌐 Explicitly specify which builds and updates to include in the comment.
name: PR Specific Builds on: pull_request: {} jobs: # ... comment_update: name: Post Update to PR after: [build_ios, build_android, publish_update] type: github-comment params: message: 'Testing builds ready for QA review' build_ids: - ${{ after.build_ios.outputs.build_id }} - ${{ after.build_android.outputs.build_id }} update_group_ids: - ${{ after.publish_update.outputs.first_update_group_id }}
排除构建、更新或部署
使用空数组来排除特定的内容类型。
🌐 Use empty arrays to exclude specific content types.
name: PR Updates Only on: pull_request: {} jobs: # ... comment_updates_only: name: Post Updates Only after: [publish_update] type: github-comment params: message: 'New update available for testing!' build_ids: [] # Empty array excludes all builds deployment_ids: [] # Empty array excludes all deployments # update_group_ids undefined = auto-discover updates
有效载荷模式示例
🌐 Payload mode examples
带有效载荷的完全自定义评论
有效载荷模式让你可以完全控制评论内容。请注意,当使用有效载荷时,你不能指定任何其他参数。
🌐 Payload mode gives you complete control over the comment content. Note that when using payload, you cannot specify any other parameters.
name: Custom PR Comment on: pull_request: {} jobs: # ... custom_comment: name: Post Custom Comment needs: [build_ios] type: github-comment params: # Payload mode: complete control over content # Cannot use message, build_ids, or update_group_ids with payload payload: | ## 🚀 Build Status Update ### iOS Build Completed - **Build ID**: `${{ needs.build_ios.outputs.build_id }}` - **Version**: ${{ needs.build_ios.outputs.app_version }} - **Build Number**: ${{ needs.build_ios.outputs.app_build_version }} ### Next Steps 1. Download the build from [EAS Dashboard](https://expo.dev/accounts/[account]/projects/[project]/builds/${{ needs.build_ios.outputs.build_id }}) 2. Test on physical device 3. Approve for TestFlight distribution --- *This comment was automatically generated by EAS Workflows*
基于构建状态的条件注释
该工作流程会根据构建是成功还是失败发布不同的评论。
🌐 This workflow posts different comments based on whether the build succeeded or failed.
name: Conditional PR Comment on: pull_request: {} jobs: build_android: name: Build Android type: build params: platform: android profile: preview comment_success: name: Post Success Comment needs: [build_android] if: ${{ needs.build_android.status == 'success' }} type: github-comment params: message: '✅ Android build succeeded! Ready for testing.' build_ids: # provided only for instructional purposes, you could as well omit this here - ${{ needs.build_android.outputs.build_id }} comment_failure: name: Post Failure Comment after: [build_android] if: ${{ after.build_android.status == 'failure' }} type: github-comment params: payload: | ❌ **Android build failed** Please check the [workflow logs](https://expo.dev/accounts/[account]/projects/[project]/workflows) for details.
需要批准
🌐 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.
jobs: web_preview: name: Deploy Web Preview type: deploy require_approval: name: Deploy Web to Production? needs: [web_preview] type: require-approval web_production: name: Deploy Web Production needs: [require_approval] type: deploy params: prod: true
工作流的控制流
此工作流程允许用户在揭示结局之前,通过要求批准来决定故事如何结束。
🌐 This workflow lets a user decide how the story ends by requiring approval before revealing the conclusion.
jobs: show_story_intro: name: Dragon and Knight Story Intro type: doc params: md: | # The Dragon and the Knight Once upon a time, in a land far away, a brave knight set out to face a mighty dragon. The dragon roared, breathing fire across the valley, but the knight stood firm, shield raised high. Now, the fate of their encounter is in your hands... require_approval: name: Should the knight and dragon become friends? needs: [show_story_intro] type: require-approval happy_ending: name: Friendship Ending needs: [require_approval] type: doc params: md: | ## A New Friendship The knight lowered his sword, and the dragon ceased its fire. They realized they both longed for peace. From that day on, they became the best of friends, protecting the kingdom together. epic_battle: name: Epic Battle Ending after: [require_approval] if: ${{ failure() }} type: doc params: md: | ## The Epic Battle The knight charged forward, and the dragon unleashed a mighty roar. Their battle shook the mountains and echoed through the ages. In the end, both were remembered as fierce and noble adversaries.
文档
🌐 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:
| 参数 | 类型 | 描述 |
|---|---|---|
| md | 字符串 | 必填。要显示的 Markdown 内容。你可以使用 ${{ ... }} 工作流插值。 |
示例
🌐 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.
jobs: build_ios: name: Build iOS type: build params: platform: ios profile: production submit: name: Submit to App Store type: submit needs: [build_ios] params: build_id: ${{ needs.build_ios.outputs.build_id }} profile: production next_steps: name: Next Steps needs: [submit] type: doc params: md: | # To do next Your app has just been sent to [App Store Connect](https://appstoreconnect.apple.com/apps). 1. Download the app from TestFlight. 2. Test the app a bunch. 3. Submit the app for review.
重新打包
🌐 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 message: string # optional repack_version: string # optional
注意: 如果构建可能仍在进行中,请使用
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:
| 参数 | 类型 | 描述 |
|---|---|---|
| build_id | string | 必填。要重新打包的构建的源构建 ID。 |
| profile | string | 可选。要使用的构建配置文件。默认使用从 build_id 获取的源构建的配置文件。 |
| embed_bundle_assets | boolean | 可选。是否在重新打包的构建中嵌入打包资源。默认情况下,此值根据源构建自动确定。 |
| js_bundle_only | boolean | 可选。是否仅重新打包 JavaScript 打包包。默认值为 false,表示将更新整个应用元数据。 |
| message | string | 可选。附加到构建的自定义消息。对应运行 eas build 时的 --message 标志。 |
| repack_version | string | 可选。要使用的 @expo/repack-app 版本。默认使用最新版本。 |
示例
🌐 Examples
以下是使用指纹与重打包任务的一些实际示例:
🌐 Here are some practical examples of using the Fingerprint with Repack jobs:
使用指纹和重打包的持续部署
此工作流程首先生成指纹,然后根据是否已存在与该指纹兼容的构建来构建或重新打包应用。最后,它运行 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.
name: continuous-deploy-fingerprint jobs: fingerprint: id: fingerprint type: fingerprint environment: production android_get_build: needs: [fingerprint] id: android_get_build type: get-build params: fingerprint_hash: ${{ needs.fingerprint.outputs.android_fingerprint_hash }} platform: android android_repack: needs: [android_get_build] id: android_repack if: ${{ needs.android_get_build.outputs.build_id }} type: repack params: build_id: ${{ needs.android_get_build.outputs.build_id }} android_build: needs: [android_get_build] id: android_build if: ${{ !needs.android_get_build.outputs.build_id }} type: build params: platform: android profile: preview-simulator android_maestro: after: [android_repack, android_build] id: android_maestro type: maestro image: latest params: build_id: ${{ needs.android_repack.outputs.build_id || needs.android_build.outputs.build_id }} flow_path: ['maestro.yaml'] ios_get_build: needs: [fingerprint] id: ios_get_build type: get-build params: fingerprint_hash: ${{ needs.fingerprint.outputs.ios_fingerprint_hash }} platform: ios ios_repack: needs: [ios_get_build] id: ios_repack if: ${{ needs.ios_get_build.outputs.build_id }} type: repack params: build_id: ${{ needs.ios_get_build.outputs.build_id }} ios_build: needs: [ios_get_build] id: ios_build if: ${{ !needs.ios_get_build.outputs.build_id }} type: build params: platform: ios profile: preview-simulator ios_maestro: after: [ios_repack, ios_build] id: ios_maestro type: maestro image: latest params: build_id: ${{ needs.ios_repack.outputs.build_id || needs.ios_build.outputs.build_id }} flow_path: ['maestro.yaml']