Eas Build + Eas update with staging flow

Expo Development Tools
1

Hi,
After reading all docs about EAS build, EAS update, EAS auto submission AND Deployment pattern I’m a bit lost and don’t understand what I need to do to make it work…

My “go to” is to use staging flow (two branches) with 2 builds (production and staging => channels) + Triggering builds from CI with Automating submissions

I have several questions:

  1. How to differentiate production and staging builds?
    Both have the same version (eg 1.0.0) but they only have versionCode and buildNumber in difference.
    If it’s auto-incrementing, how can I tell which is which.

  2. Automating submissions suggest to use different bundleIdentifier/package and/or name.
    But EAS update only uses one bundleIdentifier/package with specific channel name.
    What should we do if we want to build with a specific configuration AND channel ?

  • One bundleIdentifier/package and two channels ?
  • Two bundleIdentifier/package and one channel ?

  1. If Triggering builds from CI how to differentiate if an EAS build is needed or only EAS update (small changes) ?

  2. If building needs to have there buildNumber and versionCode incremented for each new build.
    How should we do with Triggering builds from CI on staging branch AND production branch ?
    With eas.json build.xxxxx.[android/ios].autoIncrement at true, the build will trigger increment of the buildNumber and versionCode (which is good).
    But if we commit on production that triggers a CI:

  • CI will build
  • Changing the build number
  • eas.json file need to be committed (because it changes) to keep track of the last version built.
    Should we need to commit changes inside production branch AND staging branch ?
    But what if the staging is headed of production? (eg: staging => 41 and production => 38)
2

Hi!

I think at least questions 1 and 2 (and maybe 4) are answered at least in part by our document on App Variants. This explains how to setup multiple bundle ID’s for staging, production, etc. with EAS Build. For differentiating between them in CI, you could use something like Github Action’s filters, where you restrict certain jobs based on, say, branch name. It may also make sense to always run the update, but restrict the build to specific scenarios. The runtimeVersion property will prevent updates from going to builds that they cannot run on.

Finally, regarding incrementing version numbers, you may find some of the version number automation options helpful.

1 Like
3

Looking at the Variants documentation, we need to convert the app.json to app.config.js, does not that mean that autoIncrement will no longer works ?

4

That is correct. If you continue using a local version number, you may prefer to put that in a separate file you read into app.config.js to make it easier to update, or you could look at the remote versioning option.