CI builds on EAS Updates

Expo Application Services (EAS)
1

Hi Expo,

We’ve been using EAS Build for a while (with Expo dev-client) and everything has worked out great so far. We particularly like the fact that it’s always built on CI — no more environment or setup mismatch between developers who build the apps. That’s solid!

In addition to EAS Build, we’ve also been using Expo Updates for a while, though mostly for bug fixes. We’ve had to design an internal policy system around making sure that code is not pushed to an incompatible native runtime. This seems like an oversight, but we also do appreciate, that it’s a hard thing to nail consistently, with an automated system (trust me, we tried ourselves).

The issue we’ve had with Expo Updates is though, as stated above, that they’re built in the machines of the developers. If the environment or setup of one developer doesn’t match the setup used on CI, this can lead to the wrong environment variables being used or an incompatible JS build being shipped (even though the runtimes should match).

This leads us to exploring EAS Updates. Being on the production plan, we’ll begin implementing it next week. We do however, have some questions. In our case, the pitfalls that we had with Expo Updates have been the lack of a consistent build environment (preferably the same as EAS Build) and avoiding the manual process of deciding which native runtimes are compatible or not. I see that in the documentation, you’re suggesting that EAS Updates be used with a Github Action. This would create the consistent build env, albeit not the one of EAS Build. Also, this sadly makes it so that we need to automate OTA updated in a CD fashion using git, where, at least currently, we’d much rather prefer to do this manually, on a case-by-case basis.

Thus, this leaves me with the following questions:

  1. Is it supported, or have you considered, to make EAS Updates use the same way of submitting the code for Expo to then build on your servers. This streamlines the behaviour of the two tools, and the only difference would then be that EAS Updates doesn’t have to build an actual native package, but just the JS source. This would, at least for us, be great.
  2. Does EAS Updates have any heuristics to prevent an OTA update from being applied to an incompatible native runtime? (or do we have to update the runtime version manually in the config every time to signal this?)

Thanks a bunch, looking forward to integrating even more with the great tooling you’re building around Expo!

2

hi there! it’s great to hear that you’ve been enjoying our tools :slight_smile:

we have been discussing possible solutions for the exact issue that you raised about environment variables but this isn’t something that we have a good answer for at this point. i’d suggest using something like direnv and custom scripts that wrap publishing to ensure that the system is set up as needed.

re: your questions.

  1. this has been considered and isn’t off the table, but it’s not yet on the roadmap.
  2. i would suggest using the nativeVersion policy, so the runtime version will be set based on the app native version and will always be unique for every update on the store. more info here Runtime versions and updates - Expo Documentation