Executing EAS builds via GitHub Actions
In the previous blog post, we learned how to submit our React Native apps via the EAS Submit command.
It still required us to run the EAS commands manually, which we will improve with this part of the series. We'll take a look at setting up the continuous integration pipeline with EAS and GitHub Actions.
Prerequesites
-
Set up signing keys. We can run
eas credentials
to set these up before executing our first CI build. -
Obtain an Expo token. This allows CI to access Expo services programmatically.
Version management
In Expo apps, can manually manage it via the version field in app.json (ios/android)
and the ios.buildNumber
and android.versionCode
.
EAS also offers remote version management, which automatically increments the buildNumber
when you create a production build.
We typically opt for this option, as it still allows you to set the primary version, but takes care of incrementing the version code automatically.
Initiating EAS Build from CI
The process is similar to running the EAS CLI from your development machine.
We can select any CI environment that supports running a Linux machine with Node installed, which is all we need to execute the EAS CLI.
GitHub Actions is one such environment. Here is an example build file (.yml configuration file) that we can create and place in the .github/workflows/eas-build
directory:
name: EAS Build
on:
workflow_dispatch:
jobs:
build:
name: Install and build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: 18.x
cache: npm
- name: Setup Expo and EAS
uses: expo/expo-github-action@v8
with:
eas-version: latest
token: ${{ secrets.EXPO_TOKEN }}
- name: Install dependencies
run: npm ci
- name: Build on EAS
run: eas build --platform all --non-interactive
If we examine the script together, we are creating a build that can be manually triggered (the workflow_dispatch
part). The workflow has one job called "build" and it sets up Node on the latest Ubuntu machine, installs the Expo EAS CLI (inside expo/expo-github-action
), and executes the eas build
with the non-interactive
flag, which is required, as the CI cannot prompt us for any changes during the build.
Git Workflows
Once we have a team working on our React Native app, we might benefit from further automation of the build and deploy process. One of the ways to do this is by triggering the CI on different git workflows. This is especially useful when we have multiple environments that we need to publish the app to, such as development, staging, and production.
For instance, we can trigger the builds when we merge the code to the main branch, which could create a staging build. The code change for this would look like this in the GitHub actions:
name: Build and Submit staging
on:
push:
branches:
- "main"
Simplifying Github Workflows
With multiple app environments, it's beneficial to simplify the GitHub workflows. This can be achieved by creating separate workflows for each environment. For instance, you can have a workflow for the staging environment and another for the production environment. Each workflow can be triggered by different events, such as merging to the main branch or creating a new tag.
Main build file could be similar to this:
name: "EAS Build"
on:
workflow_call:
inputs:
profile:
required: true
type: string
...
And then the staging build file can provide the "profile" variable:
name: 'Staging Build'
jobs:
eas-build:
name: 'Build and Submit'
uses: ./.github/workflows/eas-build.yml
with:
profile: staging
...
Remember, the key to successful CI/CD is automation and simplicity. The easier it is to manage and understand your workflows, the more efficient your development process will be.
Resources
Programmatic access: https://docs.expo.dev/accounts/programmatic-access/#personal-access-tokens
Building on CI docs: https://docs.expo.dev/build/building-on-ci/