EAS Builds: Repacking spending 1+ minute generating Expo Update manifest

[rodperottoni]

Summary

I'm using Expo Repack in my org's repository to save time when running Maestro Tests. My setup is pretty much the same as the blog Expo published a while ago: https://expo.dev/blog/accelerating-continuous-integration-with-fingerprint-repack-in-eas-workflows#what-is-fingerprinting

I'v noticed repacks take a considerable amount of time generating app.manifest for expo-updates, even though my E2E builds don't have Expo Updates enabled. In the example workflow below, 77s were spent in that step.

Created temporary working directory: /tmp/repack-fY6g6b/working-directory
Using repack tool version: latest
Repacking the app...
Resolved runtime version: 6644bd65d01d32d3ff36e7ef77a1d36afa6819b6
Generating bundle: 100687 ms
Adding bundled resources: 184 ms
Generating 'app.manifest' for expo-updates: 77367 ms
Updating AndroidManifest.xml: 516 ms
Updating resources: 0 ms
Generating app config: 1 ms
Creating updated apk: 7610 ms
Repacked the app to /tmp/repack-fY6g6b/repacked-621ca8be-22bf-46aa-85df-4992b766a993.apk

For reference, this is my app.config.ts section on expo-update:

updates: {
        fallbackToCacheTimeout: 0,
        url: APP_UPDATES_URL,
        /**
         * Disable expo-update for E2E tests.
         */
        enabled: process.env.EXPO_PUBLIC_E2E_ENABLED !== 'true',
      },
    }),

I'm wondering if this step should be executing - even though expo updates is disabled?

[rodperottoni]

For reference, here's a workflow link showing this behaviour: https://expo.dev/accounts/amber-pli/projects/amber-electric-next/workflows/019c0798-c9b8-798a-ae38-07428260ee2e