Run your first EAS Workflows job

Create the workflow directory

Create the .eas/workflows/ directory at the root of our Expo project. EAS looks for workflow files only in this location.

Add a hello.yml file

Inside .eas/workflows/, create a file named hello.yml. This file defines our first workflow using a single custom job. The job runs a shell command that prints "Hello, Workflows":

name: Hello

jobs:
  greet:
    steps:
      - run: echo "Hello, Workflows" # Any shell command works here

The above workflow uses the following syntax:

• name is the workflow's name as shown on the EAS dashboard.
• jobs contains one or more jobs to run. Each job has a unique ID (in this case, greet).
• steps is a sequence of tasks the job executes in order. A job with steps but no type field is a custom job.
• run is the shell command to execute in a step. Here, it runs echo to print a message. Any shell command works.

Manually run the workflow

To run the workflow on the EAS dashboard, run the following command from a terminal window:

The eas workflow:run command uploads the workflow file to EAS. It then runs any job defined inside the file and the EAS CLI prints a URL to the EAS dashboard where we can watch the job.

View the job logs

Open the URL from the previous step in a browser window. On the workflow page, we can see the greet job and its status. Once the job completes, expand the step output to see the logged message: Hello, Workflows.

The EAS dashboard is where we view and debug any workflow job. The Workflow graph shows what triggered our job and the job's unique ID.

Switch to the Workflow file tab. This is the workflow file we wrote in Step 2, preserved with the run.

Tip: View all of our project's workflows and filter them by status or type on the Workflows page.

Add an automatic trigger

Let's add an on.push.branches trigger to our existing workflow file.

• The on key defines which GitHub event triggers the workflow
• The push field defines when to trigger
• The branches field allows us to specify that whenever the code is pushed to the main branch, the workflow should run automatically

name: Hello

on:
  push:
    branches: ['main'] # Fires on every push to main branch

jobs:
  greet:
    steps:
      - run: echo "Hello, Workflows"

The branches field can include any branch name that exists in a GitHub repository. We can specify multiple branches such as ['main', 'develop', 'staging'] to trigger the workflow when we push to any of those branches.

Commit the change and push to GitHub

Commit the workflow file and push it to the main branch:

Verify the automatic trigger

Tip: This step depends on our local Expo project being pushed to GitHub and the GitHub repository being connected to EAS. To confirm: run git remote -v to verify the local repo points to a GitHub URL and open the project's GitHub settings on EAS to check that a repository is connected.

Let's open our project's Workflows page on the EAS dashboard to see the new job.

In the EAS dashboard, notice that the Workflow graph tab shows the commit message and branch reference for this push. In the status under the workflow header, the Trigger and Triggered by reflect the same information.

Update hello.yml

Let's update the hello.yml file to add a custom job and a pre-packaged job. This pre-packaged job is called doc and it renders Markdown on the EAS dashboard:

name: Hello

jobs:
  greet:
    outputs:
      greeting: ${{ steps.set_greeting.outputs.greeting }} # Expose the step output at the job level
    steps:
      - id: set_greeting
        run: set-output greeting "Hello from EAS Workflows"
  show_info:
    needs: [greet] # Wait for greet to finish, then read its outputs
    type: doc # Pre-packaged job that renders Markdown on the dashboard
    params:
      md: |
        # Workflow Output
        **${{ needs.greet.outputs.greeting }}**

The above workflow file does the following:

• Defines a greet job, which is a custom job. It uses the set-output shell function to set a value called greeting. The outputs field at the job level exposes the step output so other jobs can reference it.
• Defines a show_info job which uses needs: [greet] to wait for the greet job to complete and access its output. Then, it uses the pre-packaged doc job type to render a Markdown document in the EAS dashboard. The Markdown content includes the value of greeting set in the previous job.

Tip: In EAS Workflows, jobs run in parallel by default. The needs field is what makes a job wait: it lists the job IDs that must complete successfully before the job using needs can start. If a job in the needs list fails, the dependent job is skipped.

Run the chained workflow

Run the following command from a terminal window to see the chained jobs in action:

Open the EAS dashboard link from the EAS CLI. Under Logs, notice that the greet job runs first. Once it completes, the show_info job runs and renders the Markdown content using the output from the previous job.