预打包作业
了解如何设置和使用预打包的作业。
预打包作业是随时可用的工作流作业,可帮助你自动执行常见任务,例如构建、提交和测试应用。它们提供了一种标准化的方法来处理这些操作,而无需从头编写自定义作业配置。本指南介绍了可用的预打包作业以及如何在你的工作流中使用它们。
¥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.
先决条件
¥Prerequisites
要成功使用构建作业,你需要使用与预打包作业相同的平台和配置文件,通过 EAS CLI 完成构建。了解如何使用 创建你的第一个构建 开始使用。
¥To successfully use the build job, you'll need to complete a build with EAS CLI using the same platform and profile as the pre-packaged job. Learn how to create your first build to get started.
语法
¥Syntax
jobs:
build_app:
type: build
params:
platform: android | ios # required
profile: string # optional, default: production
参数
¥Parameters
你可以将以下参数传递到 params
列表中:
¥You can pass the following parameters into the params
list:
参数 | 类型 | 描述 |
---|---|---|
platform | string | 必填。构建所针对的平台。可以是 android 或 ios 。 |
profile | string | 可选。要使用的构建配置文件。默认为 production 。 |
输出
¥Outputs
你可以在后续作业中引用以下输出:
¥You can reference the following outputs in subsequent jobs:
输出 | 类型 | 描述 |
---|---|---|
build_id | string | 已创建的构建版本的 ID。 |
app_build_version | string | 应用的版本号/内部版本号。 |
app_identifier | string | 应用的软件包标识符/包名称。 |
app_version | string | 应用的版本。 |
channel | string | 用于构建的更新渠道。 |
distribution | string | 使用的分发方法。可以是 internal 或 store 。 |
fingerprint_hash | string | 构建的指纹哈希值。 |
git_commit_hash | string | 用于构建的 git 提交哈希值。 |
platform | string | 构建所针对的平台。android 或 ios 。 |
profile | string | 使用的构建配置文件。 |
runtime_version | string | 使用的运行时版本。 |
sdk_version | string | 使用的 SDK 版本。 |
simulator | string | 构建是否用于模拟器。 |
示例
¥Examples
以下是一些使用构建作业的实际示例:
¥Here are some practical examples of using the build job:
Basic build for a specific platform
This workflow builds your iOS app whenever you push to the main branch.
!!!IG1!!!
Build for both platforms in parallel
This workflow builds both Android and iOS apps in parallel when you push to the main branch.
!!!IG2!!!
Build with environment variables
This workflow builds your Android app with custom environment variables that can be used during the build process.
!!!IG3!!!
Build with different profiles
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.
!!!IG4!!!
Deploy
Deploy your application using EAS Hosting.
Prerequisites
To deploy your application using EAS Hosting, you'll need to set up your project. See Get Started with EAS Hosting for more information.
Syntax
!!!IG5!!!
Parameters
You can pass the following parameters into the params
list:
Parameter | Type | Description |
---|---|---|
alias | string | Optional. The alias to deploy to. |
prod | boolean | Optional. Whether to deploy to production. |
Examples
Here are some practical examples of using the deploy job:
Basic deployment to production
This workflow deploys your application to production using EAS Hosting.
!!!IG6!!!
Deploy to production only on merges to the `main` branch
This workflow deploys your application to production when you merge to the main branch, and makes a non-production deployment on all other branches.
!!!IG7!!!
Deployment with custom alias
This workflow deploys your application to a custom alias in production.
!!!IG8!!!
Fingerprint
Calculates a fingerprint of your project.
Note: This job type only supports CNG (managed) workflows. If you commit your android or ios directories, the fingerprint job won't work.
Syntax
!!!IG9!!!
Parameters
You can pass the following parameters into the params
list:
Parameter | Type | Description |
---|---|---|
environment | string | Optional. The environment to use. Can be production , preview , or development . Defaults to production . |
env | object | Optional. Environment variables to use during fingerprint calculation. |
Outputs
You can reference the following outputs in subsequent jobs:
Output | Type | Description |
---|---|---|
android_fingerprint_hash | string | The fingerprint hash for Android. |
ios_fingerprint_hash | string | The fingerprint hash for iOS. |
Examples
Here are some practical examples of using the fingerprint job:
Basic fingerprint calculation
This workflow calculates fingerprints for both Android and iOS builds in the production environment.
!!!IG10!!!
Fingerprint with environment variables
This workflow calculates fingerprints with custom environment variables that can affect the build configuration.
!!!IG11!!!
Get Build
Retrieve an existing build from EAS that matches the provided parameters.
Syntax
!!!IG12!!!
Parameters
You can pass the following parameters into the params
list:
Parameter | Type | Description |
---|---|---|
platform | string | Optional. The platform to get the build for. Can be ios or android . |
profile | string | Optional. The build profile to use. |
distribution | string | Optional. The distribution method. Can be store , internal , or simulator . |
channel | string | Optional. The update channel. |
app_identifier | string | Optional. The bundle identifier/package name. |
app_build_version | string | Optional. The build version. |
app_version | string | Optional. The app version. |
git_commit_hash | string | Optional. The git commit hash. |
fingerprint_hash | string | Optional. The fingerprint hash. |
sdk_version | string | Optional. The SDK version. |
runtime_version | string | Optional. The runtime version. |
simulator | boolean | Optional. Whether to get a simulator build. |
Outputs
You can reference the following outputs in subsequent jobs:
Output | Type | Description |
---|---|---|
build_id | string | The ID of the retrieved build. |
app_build_version | string | The build version of the app. |
app_identifier | string | The bundle identifier/package name of the app. |
app_version | string | The version of the app. |
channel | string | The update channel used for the build. |
distribution | string | The distribution method used. |
fingerprint_hash | string | The fingerprint hash of the build. |
git_commit_hash | string | The git commit hash used for the build. |
platform | string | The platform the build was created for. |
profile | string | The build profile used. |
runtime_version | string | The runtime version used. |
sdk_version | string | The SDK version used. |
simulator | string | Whether the build is for simulator. |
Examples
Here are some practical examples of using the get-build job:
Get latest production build
This workflow retrieves the latest production build for iOS from the store distribution channel.
!!!IG13!!!
Get build by version
This workflow retrieves a specific version of an Android build by its app version and build version.
!!!IG14!!!
Submit
Submit an Android or iOS build to the app store using EAS Submit.
Prerequisites
Submission jobs require additional configuration to run within a CI/CD process. See our Apple App Store CI/CD submission guide and Google Play Store CI/CD submission guide for more information.
Syntax
!!!IG16!!!
Parameters
You can pass the following parameters into the params
list:
Parameter | Type | Description |
---|---|---|
build_id | string | Required. The ID of the build to submit. |
profile | string | Optional. The submit profile to use. Defaults to production . |
Outputs
You can reference the following outputs in subsequent jobs:
Output | Type | Description |
---|---|---|
apple_app_id | string | The Apple App ID of the submitted build. |
ios_bundle_identifier | string | The iOS bundle identifier of the submitted build. |
android_package_id | string | The Android package ID of the submitted build. |
Examples
Here are some practical examples of using the submit job:
Submit iOS build
This workflow submits an iOS build to the App Store using the production submit profile.
!!!IG17!!!
Submit Android build
This workflow submits an Android build to the Play Store using the production submit profile.
!!!IG18!!!
Update
Publish an update using EAS Update.
Prerequisites
To publish update previews and to send over-the-air updates, you'll need to run npx eas-cli@latest update:configure
, then create new builds. Learn more about configuring EAS Update.
Syntax
!!!IG19!!!
Parameters
You can pass the following parameters into the params
list:
Parameter | Type | Description |
---|---|---|
message | string | Optional. Message to use for the update. If not provided, the commit message will be used. |
platform | string | Optional. Platform to use for the update. Can be android , ios , or all . Defaults to all . |
branch | string | Optional. Branch to use for the update. If not provided, the branch from the workflow run will be used. For manually run workflows you need to provide a value. Example: ${{ github.ref_name || 'testing' }} . Provide either a branch or a channel, not both. |
channel | string | Optional. Channel to use for the update. Provide either a branch or a channel, not both. |
Outputs
You can reference the following outputs in subsequent jobs:
Output | Type | Description |
---|---|---|
first_update_group_id | string | The ID of the first update group. |
updates_json | string | A JSON string containing information about all update groups. |
Examples
Here are some practical examples of using the update job:
Basic update to production channel
This workflow publishes an update to the production channel whenever you push to the main branch, using the commit message as the update message.
!!!IG20!!!
Platform-specific updates
This workflow publishes separate updates for Android and iOS platforms, allowing for platform-specific changes.
!!!IG21!!!
Update with branch-based deployment
This workflow publishes updates based on the branch name, allowing for different environments (staging/production) based on the branch.
!!!IG22!!!
Maestro
Run Maestro tests on a Android emulator or iOS Simulator build.
Maestro tests are experimental and may experience flakiness.
Syntax
!!!IG23!!!
Parameters
You can pass the following parameters into the params
list:
Parameter | Type | Description |
---|---|---|
build_id | string | Required. The ID of the build to test. |
flow_path | string | Required. The path to the Maestro flow file(s) to run. |
shards | number | Optional and experimental. The number of shards to split the tests into. Defaults to 1. |
retries | number | Optional. The number of times to retry failed tests. Defaults to 1. |
record_screen | boolean | Optional. Whether to record the screen. Defaults to false. Note: recording screen may impact emulator performance. You may want to use large runners when recording screen. |
include_tags | string | Optional. Flow tags to include in the tests. Will be passed to Maestro as --include-tags . |
exclude_tags | string | Optional. Flow 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. Run sdkmanager --list on your machine to list available packages. Choose an x86_64 variant. Examples: system-images;android-36;google_apis;x86_64 , system-images;android-35-ext15;google_apis_playstore;x86_64 . Note that newer images require more computing resources, for which you may want to use large runners. |
device_identifier | string or { android?: string, ios?: string } object | Optional. Device identifier to use for the tests. You can also use a single-value expression like pixel_6 , iPhone 16 Plus or ${{ needs.build.outputs.platform == "android" ? "pixel_6" : "iPhone 16 Plus" }} and an object like device_identifier: { android: "pixel_6", ios: "iPhone 16 Plus" } . Note that iOS devices availability differs across runner images. A list of available devices can be found in the jobs logs. |
Examples
Here are some practical examples of using the Maestro job:
Basic Maestro test
This workflow runs Maestro tests on an iOS Simulator build using the default settings.
!!!IG24!!!
Maestro test with sharding
This workflow runs Maestro tests on an Android emulator build with 3 shards and 2 retries for failed tests.
!!!IG25!!!
Using Maestro prefixed environment variables
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.
!!!IG26!!!
Recording screen and using a specific device
This workflow runs Maestro tests on an Android emulator build with a specific device and records the screen.
!!!IG27!!!
Maestro Cloud
Run Maestro tests on Maestro Cloud.
This requires a Maestro Cloud account and Cloud Plan subscription. Go to Maestro docs to learn more.
Syntax
!!!IG28!!!
Parameters
You can pass the following parameters into the params
list:
Parameter | Type | Description |
---|---|---|
build_id | string | Required. The ID of the build to test. Example: ${{ needs.build_android.outputs.build_id }} . |
maestro_project_id | string | Required. The ID of the Maestro Cloud project to use. Corresponds to --project-id param to maestro cloud . Example: proj_01jw6hxgmdffrbye9fqn0pyzm0 . Go to Maestro Cloud to find yours. |
flows | string | Required. The 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 | Optional. The tags to include in the tests. Corresponds to --include-tags param to maestro cloud . Example: "pull,push" . |
exclude_tags | string | Optional. The tags to exclude from the tests. Corresponds to --exclude-tags param to maestro cloud . Example: "disabled" . |
maestro_version | string | Optional. The version of Maestro to use. Example: 1.30.0 . |
android_api_level | string | Optional. The Android API level to use. Corresponds to --android-api-level param to maestro cloud . Example: 29 . |
maestro_config | string | Optional. The path to the Maestro config.yaml file to use. Corresponds to --config param to maestro cloud . Example: .maestro/config.yaml . |
device_locale | string | Optional. The locale that will be set on devices used for the tests. Corresponds to --device-locale param to maestro cloud . Example: pl_PL . |
device_model | string | Optional. The model of the device to use for the tests. Corresponds to --device-model param to maestro cloud . Example: iPhone-11 . Run maestro cloud --help for a list of supported values. |
device_os | string | Optional. The OS of the device to use for the tests. Corresponds to --device-os param to maestro cloud . Example: iOS-18-2 . Run maestro cloud --help for a list of supported values. |
You need to either setmaestro_api_key
parameter orMAESTRO_CLOUD_API_KEY
environment variable in the job environment. Go to "Settings" on Maestro Cloud to generate an API key and then to Environment variables to add it to your project.
Examples
Here are some practical examples of using the Maestro job:
Basic Maestro Cloud test
This workflow runs Maestro tests on an iOS Simulator build using the default settings.
!!!IG29!!!
Using Maestro prefixed environment variables
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.
!!!IG30!!!
Slack
Send a message to a Slack channel using a Slack webhook URL.
Syntax
!!!IG31!!!
Parameters
You can pass the following parameters into the params
list:
Parameter | Type | Description |
---|---|---|
webhook_url | string | Required. The Slack webhook URL to send the message to. Currently only hardcoded strings are supported. Using webhooks stored in env are upcoming but not yet supported. |
message | string | Required if payload is not provided. The message to send. |
payload | object | Required if message is not provided. The Slack Block Kit payload to send. |
Examples
Here are some practical examples of using the Slack job:
Basic build notification
This workflow builds an iOS app and then sends a notification with the app identifier and version from the build job outputs.
!!!IG32!!!
Rich build notification with Block Kit
This workflow builds an Android app and sends a rich notification using the build job outputs.
!!!IG33!!!
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
!!!IG34!!!
Parameters
This job doesn't take any parameters.
Examples
Here are some practical examples of using the Require Approval job:
Ask for approval before deploying to production
This workflow deploys a web app to preview and then requires approval from a user before deploying to production.
!!!IG35!!!
Control flow of the workflow
This workflow lets a user decide how the story ends by requiring approval before revealing the conclusion.
!!!IG36!!!
Doc
Displays a Markdown section in the workflow logs.
Syntax
!!!IG37!!!
Parameters
You can pass the following parameters into the params
list:
Parameter | Type | Description |
---|---|---|
md | string | Required. The Markdown content to display. You can use ${{ ... }} workflow interpolation. |
Examples
Here are some practical examples of using the Doc job:
Display instructions
This workflow builds an iOS app and then displays a Markdown section in the workflow logs.
!!!IG38!!!
Repack
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
!!!IG39!!!
Parameters
You can pass the following parameters into the params
list:
Parameter | Type | Description |
---|---|---|
build_id | string | Required. The source build ID of the build to repack. |
profile | string | Optional. The build profile to use. Defaults to the profile of the source build retrieved from build_id . |
embed_bundle_assets | boolean | Optional. Whether to embed the bundle assets in the repacked build. By default, this is automatically determined based on the source build. |
Examples
Here are some practical examples of using the Fingerprint with Repack jobs: