[PREPARE_CREDENTIALS] Injecting signing config into build.gradle
[PREPARE_CREDENTIALS]
Error: Failed to find 'build.gradle' file for project: /home/vsts/work/_temp/61201/build/android/app.
at getGradleFilePath (/home/vsts/work/1/.nvm/versions/node/v16.18.1/lib/node_modules/eas-cli-local-build-plugin/node_modules/@expo/config-plugins/build/android/Paths.js:141:11)
at Object.getAppBuildGradleFilePath (/home/vsts/work/1/.nvm/versions/node/v16.18.1/lib/node_modules/eas-cli-local-build-plugin/node_modules/@expo/config-plugins/build/android/Paths.js:165:10)
at addApplyToBuildGradle (/home/vsts/work/1/.nvm/versions/node/v16.18.1/lib/node_modules/eas-cli-local-build-plugin/node_modules/@expo/build-tools/dist/android/gradleConfig.js:35:66)
at configureBuildGradle (/home/vsts/work/1/.nvm/versions/node/v16.18.1/lib/node_modules/eas-cli-local-build-plugin/node_modules/@expo/build-tools/dist/android/gradleConfig.js:20:11)
at async /home/vsts/work/1/.nvm/versions/node/v16.18.1/lib/node_modules/eas-cli-local-build-plugin/node_modules/@expo/build-tools/dist/builders/android.js:44:13
at async BuildContext.runBuildPhase (/home/vsts/work/1/.nvm/versions/node/v16.18.1/lib/node_modules/eas-cli-local-build-plugin/node_modules/@expo/build-tools/dist/context.js:72:28)
at async buildAsync (/home/vsts/work/1/.nvm/versions/node/v16.18.1/lib/node_modules/eas-cli-local-build-plugin/node_modules/@expo/build-tools/dist/builders/android.js:42:9)
at async runBuilderWithHooksAsync (/home/vsts/work/1/.nvm/versions/node/v16.18.1/lib/node_modules/eas-cli-local-build-plugin/node_modules/@expo/build-tools/dist/builders/common.js:13:13)
at async Object.androidBuilder (/home/vsts/work/1/.nvm/versions/node/v16.18.1/lib/node_modules/eas-cli-local-build-plugin/node_modules/@expo/build-tools/dist/builders/android.js:15:12)
at async buildAndroidAsync (/home/vsts/work/1/.nvm/versions/node/v16.18.1/lib/node_modules/eas-cli-local-build-plugin/dist/android.js:62:12)
Build failed
For iOS (macos-12)
[PREBUILD] yarn run v1.22.19
[PREBUILD] $ /Users/runner/work/_temp/61201/build/node_modules/.bin/expo prebuild --no-install --platform ios
[PREBUILD] - Creating native project directories (./ios and ./android) and updating .gitignore
[PREBUILD] Unexpected end of JSON input
[PREBUILD] - Creating native project directories (./ios and ./android) and updating .gitignore
[PREBUILD] ✖ Failed to create the native project.
[PREBUILD] You may want to delete the `./ios` and/or `./android` directories before trying again.
[PREBUILD] Done in 3.29s.
[PREBUILD] Running "yarn install" in the root dir of your repository
[PREBUILD] yarn install v1.22.19
[PREBUILD] [1/4] Resolving packages...
[PREBUILD] success Already up-to-date.
[PREBUILD] $ husky install || true
[PREBUILD] fatal: not a git repository (or any of the parent directories): .git
[PREBUILD] Done in 2.26s.
[INSTALL_PODS]
[INSTALL_PODS]
Error: spawn pod ENOENT
Unfortunately this is the corporate project so I can’t show the code unlike my PoC
The key problem I can tell is
[PREBUILD] Unexpected end of JSON input
but the thing is which JSON file is it failing on?
another possibility is it looks like you may have a config plugin that is not working as expected. try getting prebuild running locally for your project. use DEBUG=* npx expo prebuild to debug it
Downloading the file yield the same SHASUM so there’s something else I am missing I think
I am wondering if it is
expo:api:fetch:base
Where does it get the authentication? Did it change?
I modified the expo/wrapFetchWithBaseUrl.ts at main · expo/expo (github.com) so it outputs the init value and it looks like it’s sending a Bearer token rather than Basic auth. Passing the bearer token to curl just gives 401 which is probably why it’s failing.
I did an npm login and re-entered my credentials no luck
My suspicion so far is somewhere between these version and the current version there was a change to the @expo/cli … npm.js code to make it emulate npm to download the files but it does it incorrectly when it came to the authentication tokens. Perhaps the older version relied on npm itself or their libraries rather than doing the fetch manually. Mind you this is just a guess I can’t confirm if that is the case or not.
I hadn’t tested @wodin solution, our builds are pretty slow and it’s gotten back to a working state again by locking to eas-cli@0.55 as a bonus it can autodetect the EAS Application ID which was needed in newer versions.
Since i have a single code base for multiple apps this was a convenient feature since developers can have their own EAS builds without being associated with the build server’s account. Having that eas application ID meant that the developer had to modify the application.config.js to contain the specific value for his account when they wanted to experiment on their own dev client.