after context in EAS Workflows
The after context is a record of upstream jobs listed in the current job's after field, whether or not they succeeded. Each entry provides the same status and outputs shape as the needs context.
eas-workflows
363 notes in this subject, read out of this brain and free to use. This is page 2 of 7.
steps context in EAS Workflows
The steps context is a record of the steps in the current job, keyed by step id. Each entry exposes the outputs set with the set-output function. This context is only available within a job's steps.
Example: Workflow completion notification with workflow context in EAS Workflows
```yaml jobs: notify: type: slack params: message: | Workflow run completed: ${{ workflow.name }} View details: ${{ workflow.url }} ``` This example shows using the workflow context to include the workflow name and dashboard URL in a notification.
needs context in EAS Workflows
The needs context is a record of upstream jobs listed in the current job's needs field. Each entry provides the job's status (success, failure, or skipped) and its outputs.
Define custom environment variables in EAS Workflows job
Use the env key on a job to define custom variables. Values can reference other context properties using the ${{ ... }} interpolation syntax.
EAS Workflows ccache steps
For EAS Workflows, use eas/restore_cache and eas/save_cache actions to manage ccache. Alternatively, use eas/restore_build_cache and eas/save_build_cache which are equivalent and automatically use ccache cache patterns. The cache key is automatically generated as a hash of the package manager lock file.
Android ccache example workflow
Example EAS Workflow for Android with ccache: ```yaml jobs: build_android: type: build steps: - uses: eas/checkout - uses: eas/restore_build_cache - uses: eas/build - uses: eas/save_build_cache ```
iOS ccache example workflow
Example EAS Workflow for iOS with ccache: ```yaml jobs: build_ios: type: build steps: - uses: eas/checkout - uses: eas/restore_build_cache - uses: eas/build - uses: eas/save_build_cache ```
Custom ccache restore and save in workflows
In EAS Workflows, you can customize cache keys and paths using eas/restore_cache and eas/save_cache with parameters: key (cache key pattern), restore_keys (prefix patterns for fallback), and path (directory to cache). Android ccache is cached at /home/expo/.cache/ccache and iOS at /Users/expo/Library/Caches/ccache.
Designated cache creation job workflow example
Example workflow to ensure only trusted sources publish cache: ```yaml jobs: build_production: type: build if: ${{ github.ref_name == 'main' }} env: EAS_RESTORE_CACHE: '0' EAS_SAVE_CACHE: '1' params: platform: android profile: production ```
EAS Workflows for automated builds from GitHub
Use EAS Workflows to automate builds when code is pushed to GitHub. Create a workflow file in .eas/workflows/build.yml. Example workflow: set 'name: Build', trigger 'on: push' with 'branches: [main]', then define jobs with 'type: build' and 'params: platform: android' or 'platform: ios'. This creates Android and iOS builds when commits are pushed to main branch.
Build triggers deprecated for new projects
The build triggers feature is deprecated and disabled for new projects. Expo recommends using EAS Workflows instead for automating builds when pushing code to GitHub.
EAS Workflows build configuration
To create builds with EAS Workflows, add code in .eas/workflows/build.yml. When a commit is pushed to the main branch, the workflow will create Android and iOS builds. The workflow file contains a name field, on trigger configuration specifying push events on the main branch, and jobs section defining build_android and build_ios jobs with type: build and platform parameters.
EAS Workflows build.yml example
name: Build on: push: branches: - main jobs: build_android: name: Build Android App type: build params: platform: android build_ios: name: Build iOS App type: build params: platform: ios
EAS Build integrates with EAS Workflows
EAS Build integrates with EAS Workflows using the build job type. Add a build job to your workflow configuration with params for platform (android, ios, or all) and optionally a profile parameter. The build job supports conditional builds based on branch references.
EAS Build with CI pipelines
EAS Build supports builds from GitHub and building on CI with any CI provider. This allows you to automate builds as part of your continuous integration pipeline.
EAS Workflows Insights availability and plans
EAS Workflows Insights is available only on Production and Enterprise plans. It is not available on lower-tier plans.
How to access EAS Workflows Insights
To view EAS Workflows Insights, open your project in the EAS dashboard, select Insights from the navigation menu, and then select the Workflows tab.
EAS Workflows Insights export formats
You can export the workflow runs that match your current filters and time range as CSV or newline-delimited JSON (NDJSON) for further analysis.
EAS Workflows Insights overview metrics
The overview section at the top of the Workflows tab displays four summary metrics for the selected time range: Total runs (how many workflow runs started), Success rate (the share of runs that succeeded), Active workflows (how many distinct workflows ran), and Failed runs (how many runs failed).
EAS Workflows Insights runs over time chart
A chart breaks down runs by day (or by hour or minute for shorter time ranges) into total, successful, failed, and canceled runs. You can toggle between a line view and a stacked view, and turn individual statuses on or off to focus on specific data.
EAS Workflows Insights time range and comparison
When viewing EAS Workflows Insights, you can choose a time range to load data. Every metric automatically compares against the previous period of equal length so you can see whether numbers are trending up or down.
EAS Workflows Insights table columns
The workflows table displays each workflow that ran in the time range with the following columns: Runs (total count broken down into succeeded, failed, and canceled), Success rate (the share of runs that succeeded), and Last run (when the workflow last ran).
EAS Workflows Insights filter options
You can filter EAS Workflows Insights data by workflow, run status (success, failure, canceled), trigger type (manual, schedule, or a GitHub event), or git ref. You can also search by workflow name.
EAS Workflows Insights data lag and limitations
Insights are aggregated for trend analysis and can lag behind real time or omit recent runs. Exports should be used to investigate trends rather than as an authoritative record for billing or auditing.
Override working_directory in function call example
Example of overriding working_directory in a function call: ```yaml build: name: List files steps: - eas/checkout - list_files: working_directory: /a/b/c ``` This lists files in the specified directory instead of the project root.
Override values in build step execution
You can override values for the following properties when calling build steps: working_directory, name, and shell. For example, you can override working_directory to change where a command executes.
Reusable function definition and usage in build
Reusable functions can be defined with inputs and used in build steps. Example function definition: ```yaml functions: greetings: - name: name default_value: Hello world inputs: [value] command: echo "${ inputs.name }, ${ inputs.value }" ``` The function can be called in a build as follows: ```yaml build: name: Functions Demo steps: - greetings: inputs: value: Expo ``` build.steps can execute multiple reusable functions sequentially.
Example: Build and update job workflow with environment
name: Publish preview build and update jobs: build_preview: type: build params: platform: ios profile: preview # uses environment from eas.json's build.preview.environment publish_preview_update: needs: [build_preview] type: update environment: preview # pulls variables from the preview environment params: branch: preview
Setting environment explicitly in EAS Workflow jobs
Set environment explicitly on a job to override its default and keep it in sync with the build profile used earlier in the workflow. This prevents mismatched secrets between jobs.
Default environment for EAS Workflow jobs
When jobs.<job_id>.environment is omitted, the default depends on job type: Build jobs inherit environment from build.<profile>.environment in eas.json, or use automatic defaults (production when distribution is store, development when developmentClient is true, preview otherwise). Submit jobs inherit environment from the submitted build. Maestro jobs (maestro and maestro-cloud) default to preview. Other jobs (update, fingerprint, deploy, custom) default to production.
Example: Fingerprint and build workflow with environment
name: Fingerprint and build jobs: fingerprint: type: fingerprint environment: production # defaults to production, but set explicitly to match the build build_ios: needs: [fingerprint] type: build params: platform: ios profile: production # uses environment from eas.json's build.production.environment
EAS Workflows deployment automation overview
EAS Workflows is a way to automate the React Native CI/CD pipeline for deploying websites and API routes to EAS Hosting with pull request previews and production deployments.
Production deployment workflow file location and configuration
Create a deployment workflow by adding a file to .eas/workflows/deploy.yml. The workflow uses type 'deploy', specifies the production environment, sets params.prod to true, and automatically deploys whenever a commit is pushed to the main branch or a PR is merged.
GitHub integration for EAS Workflows
You can add the GitHub integration to connect a GitHub repository to your EAS Workflows.
PR preview workflow trigger events
The PR preview workflow runs whenever a pull request is opened, reopened, or synchronized. The comment job automatically discovers the deployment and posts its details to the pull request.
PR preview workflow example
The PR preview workflow file at .eas/workflows/pr-preview.yml contains: name: PR Preview on: pull_request: {} jobs: deploy: type: deploy name: Deploy PR Preview comment: needs: [deploy] type: github-comment
PR preview workflow file location and configuration
Create a PR preview workflow by adding a file to .eas/workflows/pr-preview.yml. The workflow automatically deploys a preview whenever a pull request is created or updated, and posts a comment to the PR with deployment details.
Manual workflow trigger command
You can test a workflow by manually triggering it using the command: eas workflow:run .eas/workflows/deploy.yml
Deploy workflow example for production
The production deployment workflow file at .eas/workflows/deploy.yml contains: name: Deploy on: push: branches: ['main'] jobs: deploy: type: deploy name: Deploy environment: production params: prod: true
EAS Workflows purpose
EAS Workflows automates your development and release workflows with CI/CD jobs.
EAS Workflows file location and naming
Workflow files must be created at the root of your project in the .eas/workflows/ directory with a .yml extension. For example, build-ios-production.yml would be located at .eas/workflows/build-ios-production.yml.
iOS production build workflow example
To create an iOS production build with workflows, create .eas/workflows/build-ios-production.yml with the following content: name: iOS production build on: push: branches: ['main'] jobs: build_ios: name: Build iOS type: build params: platform: ios profile: production
EAS Workflows overview and purpose
EAS Workflows automate sequences of EAS CLI commands. They can build, submit, and update your app, while also running other jobs like Maestro tests, unit tests, and custom scripts.
Workflow job dependencies with needs
In EAS Workflows, use the 'needs' field to specify job dependencies. For example, 'needs: [build_ios]' makes a submit job depend on a build job, and allows accessing outputs from the build job using ${{ needs.build_ios.outputs.build_id }}.
EAS update workflow example
To publish an over-the-air update with workflows, create .eas/workflows/publish-update.yml with the following content: name: Publish update on: push: branches: ['*'] jobs: update: name: Update type: update params: branch: ${{ github.ref_name || 'test'}}
Submit build workflow requires build_id
The submit job in EAS Workflows requires the ID of the build to submit. You can provide this directly or use the get-build job to look one up dynamically. The build_id can be passed from a previous build job using ${{ needs.build_ios.outputs.build_id }}.
Run workflow with eas workflow:run command
Execute a workflow file by running 'eas workflow:run' followed by the path to the workflow file, for example: eas workflow:run .eas/workflows/build-ios-production.yml.
Branch cleanup workflow with EAS Workflows
A complete workflow example that deletes EAS Update branches when GitHub branches are deleted. The workflow uses the `ref_delete` trigger on all branches except `main`, and executes a `branch-delete` job with `params.branch_name` set to `${{ github.ref_name }}`. With default `fail_on_missing: false`, the job succeeds even if the EAS Update branch does not exist or was already deleted. The workflow file must be kept on the repository's default branch, as EAS reads workflow configuration from the default branch HEAD when a branch is deleted, not from the deleted ref.
Prerequisites for branch cleanup workflow
Before using the branch cleanup workflow, your project must have EAS Update configured (via `eas update:configure`), your EAS project must be linked to a GitHub repository as described in the EAS Workflows getting started guide, and the workflow file must be kept on your repository's default branch.
Protect branches from automatic cleanup using negation patterns
Use negation patterns in `on.ref_delete.branches` to prevent specific branches from being automatically cleaned up. For example, `!main` or `!release/**` excludes those branches from the deletion trigger. This ensures important branches are never cleaned up when deleted.
Channel mappings block branch deletion
If an EAS channel points to an EAS Update branch, attempting to delete that branch will fail with an error about the channel mapping. The branch cannot be deleted while a channel still maps to it.
branch-delete job in EAS Workflows
The `branch-delete` job deletes an EAS Update branch. It accepts a `params.branch_name` parameter to specify which branch to delete. By default, `fail_on_missing` is set to false, meaning the job succeeds even if the specified EAS Update branch does not exist or was already deleted.
ref_delete trigger for EAS Workflows
`on.ref_delete` runs when a GitHub branch matching the specified patterns is deleted. It can be configured with a `branches` pattern list using wildcards and negation patterns (e.g., `['*', '!main']` triggers on all branches except main). The `github.sha` context in ref_delete runs refers to the default branch, not the deleted ref's last commit.
Run development builds workflow
Execute a development builds workflow using the command: eas workflow:run .eas/workflows/create-development-builds.yml
EAS Workflow YAML example for development builds
name: Create development builds jobs: android_development_build: name: Build Android type: build params: platform: android profile: development ios_device_development_build: name: Build iOS device type: build params: platform: ios profile: development ios_simulator_development_build: name: Build iOS simulator type: build params: platform: ios profile: development-simulator
Development builds workflow creates builds for all platforms and device types
A development builds workflow can create builds for Android, iOS physical devices, and iOS simulators. These builds all run in parallel.
Deploy to production workflow YAML structure
The workflow file is located at .eas/workflows/deploy-to-production.yml. It has name 'Deploy to production', triggers on push to 'main' branch, and contains nine jobs: fingerprint, get_android_build, get_ios_build, build_android, build_ios, submit_android_build, submit_ios_build, publish_android_update, and publish_ios_update.
EAS Workflows common use cases
EAS Workflows can automate development, review, and release processes. Common workflows include: creating development builds in parallel for each platform, publishing preview updates for each commit on every branch, deleting EAS Update branches when GitHub branches are deleted, building and submitting to the app stores or sending an over-the-air update when merging to main, and running E2E tests.
Maestro directory structure for test flows
Create a .maestro directory at the root of the project at the same level as eas.json. Place Maestro test flow files (.yml format) inside this directory. The flows are referenced by their relative path in workflow configuration.