Recipe: Update unless changes require a new build

[moxen-dev]

Topic and scope of discussion

How would you summarise and scope the issue?

The current recipe presented on the README file present a scenario where every time someone pushes to main, it generates a new build.

I believe could be great to have a scenario of every time someone pushes to main, it checks if the changes affect native code. If yes, new build, if not, new update.

Motivation

Why should we have this discussion?

Lots of projects needs to expose native code even if using expo config plugins to manage it for them. The project I am working on is on that intermediary level between fully managed and bare. I use prebuild a lot if I do any changes that affect native code and end bumping the run time version after this.

For strict typescript changes, I skip the prebuild and deploy the changes using eas update.

I want the Github Actions to know if it needs to build a new version or needs to update the current version.

I am trying to do this using dorny/paths-filter@v2 to check if the following files were changed:

    - uses: dorny/paths-filter@v2
      id: filter
      with:
        filters: |
          files:
            - 'eas.json'
            - 'app.config.js'
            # firebase config 
            - 'config/**'
            - 'package.json'
            - 'package-json.lock'

But I am struggling to make it work properly.

Possible outcomes of this discussion could be:

• Is this a good way to frame the problem (github actions to fork between build and update)?
• What is the best way to achieve this?
• Can this expo extension help on that in any way?

I think this could be great to reduce the amount of times EAS is requested to build something and reduce the time to put code live, improving developer and business folks experience.

[jmatsushita]

Hey @moxen-dev I'm interested in the same functionality and would also really like a recipe in the expo docs for this.

But I am struggling to make it work properly.

Can you give more details about what didn't work when you tried?

It seems like there are a lot of cases to consider and path filters might be a good "coarse" approach, but if you wanted to be more "fine-grained" in practice you would need to differentiate between package.json changes which touch native code from those who don't.

I use prebuild a lot if I do any changes that affect native code and end bumping the run time version after this.

Maybe instead the key is there, and this approach could be using a manual bump to the runtimeVersion, meaning the approach would work with https://docs.expo.dev/eas-update/runtime-versions/#custom-runtimeversion

{
  "expo": {
    "runtimeVersion": "1.0.0"
  }
}

When a runtimeVersion change would be detected, then an eas build would be ran (with an optional eas update as you might want all your deployments to have corresponding updates), if not just an eas update.

Using the custom runtimeVersion might be a good a simple API:

• It would mean less complex dependencies with automated version management with policies.
• It's a simple way to trigger what CI should do,
• and down the road, it would allow developing custom tooling to bump the runtimeVersion in CI (possibly via parsing package.json and detecting changes to react-native-* deps, or other custom approaches).