Create preview builds for pull requests with EAS Workflows

Add a preview.yml

Inside .eas/workflows/, let's add a new file called preview.yml. This workflow file uses the preview profile.

name: Preview builds

jobs:
  fingerprint:
    name: Fingerprint
    type: fingerprint
    environment: preview
  get_android_build:
    name: Check for existing Android build
    needs: [fingerprint]
    type: get-build
    params:
      fingerprint_hash: ${{ needs.fingerprint.outputs.android_fingerprint_hash }}
      profile: preview
  get_ios_build:
    name: Check for existing iOS build
    needs: [fingerprint]
    type: get-build
    params:
      fingerprint_hash: ${{ needs.fingerprint.outputs.ios_fingerprint_hash }}
      profile: preview
  build_android:
    name: Build Android
    needs: [get_android_build]
    if: ${{ !needs.get_android_build.outputs.build_id }}
    type: build
    params:
      platform: android
      profile: preview
  build_ios:
    name: Build iOS
    needs: [get_ios_build]
    if: ${{ !needs.get_ios_build.outputs.build_id }}
    type: build
    params:
      platform: ios
      profile: preview

Run the workflow

Run the workflow manually using the following command:

In the EAS dashboard, notice that the workflow follows the same fingerprint pattern we implemented for development builds. Since we are creating the preview build for the first time, it runs the build jobs for Android and iOS. If we push another commit to the main branch without changing native code, the workflow skips the build jobs since compatible builds already exist.

Create a Slack webhook URL

To send messages from EAS Workflows to our Slack channel, we need a webhook URL from Slack's settings:

1. Go to api.slack.com/apps and create a new Slack app (or use an existing one).
2. Under Features, select Incoming Webhooks and toggle it on.
3. Click Add New Webhook and select the channel to publish notifications.
4. Copy the webhook URL. It looks like: https://hooks.slack.com/services/TD000/B000/XXXXXXXXXX
5. Add the webhook URL as an EAS environment variable named SLACK_WEBHOOK_URL. Open our project's Environment variables page on the EAS dashboard, create the variable for the preview environment, and set its visibility to secret since only EAS servers need to read it. Alternatively, create it with EAS CLI:

Add a Slack notification job

Let's update preview.yml to add a notify job after the build jobs. The notify job uses webhook_url and message parameters, or a payload parameter for rich formatting with Slack Block Kit. The job reads the webhook URL from the SLACK_WEBHOOK_URL environment variable we created earlier through its environment field. Jobs default to the production environment, so setting environment: preview here is what makes the variable available.

name: Preview builds

jobs:
  fingerprint: # ...
  get_android_build: # ...
  get_ios_build: # ...
  build_android: # ...
  build_ios: # ...
  notify:
    name: Notify on Slack
    after: [build_android, build_ios]
    type: slack
    environment: preview
    params:
      webhook_url: ${{ env.SLACK_WEBHOOK_URL }}
      message: 'Preview builds are ready - Android: ${{ after.build_android.status }}, iOS: ${{ after.build_ios.status }}'

The after field ensures the notification fires once the builds finish, regardless of the outcome. The message uses ${{ after.build_android.status }} and ${{ after.build_ios.status }} to include each platform's outcome (success, failure, or skipped). The team sees what happened without leaving Slack.

Run the workflow

Run the workflow manually using the following command:

On the EAS dashboard, we can verify that the Notify on Slack job runs successfully.

We can also verify this in the Slack channel integrated with the app.

Create a pr-preview.yml

Inside .eas/workflows/, let's add a new file called pr-preview.yml. This workflow runs when a pull request is created using the on.pull_request trigger. It only publishes an update using the update job type and then posts a comment on the PR with the link to the update.

name: PR Preview

on:
  pull_request:
    branches: ['*']

jobs:
  publish_preview:
    name: Publish PR preview update
    type: update
    environment: preview
    params:
      channel: preview
  comment:
    needs: [publish_preview]
    type: github-comment

Before testing the above workflow, commit pr-preview.yml and push it to the main branch of our GitHub repository. EAS Workflows reads workflow files from the default branch.

Test with a pull request

Let's test the workflow by creating a pull request in our GitHub repository. A pull request requires a separate branch from main. Run the following command to create and switch to a new branch:

Now, let's make a visible change in the Expo project (for example, change a text string or background color). Then, commit and push the branch:

Open a pull request from test-preview to main on GitHub. The workflow runs automatically after we have created a pull request. On the EAS dashboard, we can verify that the publish_preview job runs first and the comment job runs after it succeeds.

On the GitHub pull request, a comment should appear with a link or QR code to test the update on a device.

Using the link or QR code in the comment, we can now open the update on our device or emulator/simulator and test the changes.