It appears that the macOS
machine type (runs-on
) in GitHub Actions (CI/CD) sets RCT_NO_LAUNCH_PACKAGER=1
. I verified that behavior by creating a bare repo with a simple GH workflow for macOS and verified the ENV var is set.
RCT_NO_LAUNCH_PACKAGER=1
That variable is problematic. It has a significant impact on the Xcode build process. The default Start packager
Build Phase in Xcode will not start the metro packager if RCT_NO_LAUNCH_PACKAGER
is set, which is the case here.
...if [ -z "${RCT_NO_LAUNCH_PACKAGER+xxx}" ] ; then...
Because the packager never starts, the Bundle React Native code and images
run script is doomed to failure. The build fails with this error and the JS bundle is never generated for the app archive because the packager is not running.
** ARCHIVE FAILED **
The following build commands failed:PhaseScriptExecution Bundle\ React\ Native\ code\ and\ images ...(1 failure)[23:43:23]: Exit status: 65
This is the specific part of that build phase that fails.
+ ../node_modules/expo-updates/scripts/create-manifest-ios.shError: Failed to connect to the packager server. If you did not start this build by running 'react-native run-android', you can start the packager manually by running 'react-native start' in the project directory. (Error: connect ECONNREFUSED 127.0.0.1:8081) at /Users/will/dev/changes/node_modules/expo-updates/scripts/createManifest.js:40:11 at processTicksAndRejections (internal/process/task_queues.js:93:5)
A few questions come to mind:
- Why would GitHub set that var? I can't find any meaningful documentation on it. By default, it breaks the "normal" Xcode React Native build process.
- The ENV var seems intentionally set by GitHub, so what's the alternative they're pushing users towards in order to generate a React Native iOS build?
- Unsetting
RCT_NO_LAUNCH_PACKAGER
seems like a viable options, but are there drawbacks to that approach? I'd assume it was initially set for a good reason.
I realize the react-native bundle
command exists and allows for explicitly bundling JS assets, but it seems odd to have to do that when we already have a perfectly good Bundle React Native code and images
build phase that's meant to accomplish exactly that.