As you use Expo more, you'll start to notice build times with EAS can take a very long time to complete. Tappr takes upwards of 20 minutes, but this does include waiting for it to finish the EAS queue, so it's not that bad. One of the main factors of build time is the number of people also using EAS, the more people using it, the longer you'll have to wait. However, I would prefer to turn off my computer and go to do something else while it builds and releases to the App Store. To avoid having to leave my computer running for an unnecessary amount of time, I set up a GitHub Action.
I have a script that runs locally which handles sending to be built on EAS, then uploading to App Store Connect. This script has to be run from beginning to end or it'll only build on EAS and not move on to the next steps. As I said; this can take a while to run.
My computer kicks out quite a lot of heat, and with temperatures rising over the summer, I really don't want to leave it running longer than needed.
Below is an example of what you can do to handle automatic building and releasing to the App Store. In this example, the Action runs whenever you create a new Release on GitHub.
Let's break this down a bit. Most of it is self-explanatory though.
Initially, we want to set the name of the Action. For me, I've simply called it "EAS Production" as, in my context, this runs on Production!
We then set when we want the Action to run. GitHub is a bit of a bitch with this part. The docs aren't the easiest to understand, so I made it nice and simple so it only runs when a new Release is Published.
The next parts are pretty simple.
We're setting up the name of the Job, what OS it uses to run the build and the different steps of the Job.
Just a note, I use Yarn as my package manager of choice. If you use NPM then swap yarn for npm.
You'll notice there's also a 'token' option in there. That allows the Action to connect to your Expo account and EAS.
That token can be generated from your Expo account settings, then under Access Tokens. Generate a new token, and title it something like GitHub Actions to more easily identify it. You can then set it as a secret under your Repo settings.
The rest is, yet again, pretty self-explanatory, you're installing the dependencies with the usual command.
--frozen-lockfile essentially tells yarn or npm to not update the lockfile.
After that, you're just running your usual commands. No need to do anything with any build artifacts since Expo handles that with the --latest. Argument. This tells EAS to use the latest build on the Expo servers.