Help: Error: pod exited with non-zero code: 1

[twindev]

Expo CLI 4.1.6 environment info:
System:
OS: macOS 11.2.3
Shell: 5.8 - /bin/zsh
Binaries:
Node: 12.18.3 - /usr/local/bin/node
Yarn: 1.22.5 - ~/.yarn/bin/yarn
npm: 6.14.11 - ~/node/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
Managers:
CocoaPods: 1.10.1 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: iOS 14.4, DriverKit 20.2, macOS 11.1, tvOS 14.3, watchOS 7.2
IDEs:
Android Studio: 4.1 AI-201.8743.12.41.6953283
Xcode: 12.4/12D4e - /usr/bin/xcodebuild
npmPackages:
expo: 40.0.1 => 40.0.1
react: ^17.0.1 => 17.0.1
react-dom: ^17.0.1 => 17.0.1
react-native: 0.64.0 => 0.64.0
react-native-web: 0.15.0 => 0.15.0
npmGlobalPackages:
expo-cli: 4.1.6
Expo Workflow: bare

I just upgraded to RN 0.64.0 and when running a build service following error msg is thrown:
Error: pod exited with non-zero code: 1

Reading the [stderr] [!] The version of CocoaPods used to generate the lockfile (1.10.1) is higher than the version of the current executable (1.10.0). Incompatibility issues may arise.

and
later on [!] React requires CocoaPods version >= 1.10.1, which is not satisfied by your current version, 1.10.0.

I have CocoaPods 1.10.1 installed as per above diagnostics.
I have checked every corner and it says I have CocoaPods 1.10.1 installed required by React.
I can not wrap my head around what is failing unless there is a Swift issue/package involved that struggles
BR
/Johan - really a fan of Expo and EAS

[wkozyra]

I have CocoaPods 1.10.1 installed as per above diagnostics.

but eas worker have 1.10.0, we will update our images soon, but for now you can force different version of cocoapods in eas.json Configure EAS Build with eas.json - Expo Documentation

Current version of software installed on the eas worker is listed here Build server infrastructure - Expo Documentation

[twindev]

You are a hero wkozyra! (In fact the whole Expo team). Crisp and clear answer, crisp and clear doc. Just configured eas.json and everything worked out smoothly.
Many Thanks Johan

[twindev]

Just sharing my eas.json if someone else hits the roadblock
{
“builds”: {
“android”: {
“release”: {
“workflow”: “generic”
},
“testing”: {
“distribution”: “internal”,
“workflow”: “generic”
}
},
“ios”: {
“release”: {
“workflow”: “generic”
},
“testing”: {
“distribution”: “internal”,
“workflow”: “generic”
},
“override”: {
“workflow”: “generic”,
“extends”: “override”,
“credentialsSource”: “remote”,
“releaseChannel”: “default”,
“distribution”: “internal”,
“autoIncrement”: false,
“image”: “latest”,
“node”: “14.16.0”,
“yarn”: “1.22.5”,
“cocoapods”: “1.10.1”
}
}
}
}
/Johan

[wkozyra]

Hi @twindev

“override”: {
  “workflow”: “generic”,
  “extends”: “override”,

Is not correct (it’s a dependency cycle), it’s working, because of a bug in our validation code, it will be fixed in next eas-cli release.

Also, take into account that specifying versions explicitly is increasing a build time.

[twindev]

Thanks for the feedback, I read-up on your links and followed the instruction i.e. added a complementary build profile (named it override) with the toolchain I needed (or RN 0.64.0 requires cocoapods 1.10.1 and hence forced me to add a profile). Once the image is updated with 1.10.1 I will rely back on my usual build profile (testing). The build time is ok, I did not experience too much weight in that.
Please advice how to proceed or needed changes and I will update.
BR
/Johan

[twindev]

Hi @wkozyra,
I saw that you have released a new eas-cli (0.7.0) is the toolchain in the image updated also i.e. cocoalpods 1.10.1?
BR
/Johan

[wkozyra]

added a complementary build profile (named it override) with the toolchain I needed

By incorrect, I meant that you are extending profile with itself (it will throw an error with latest cli), you should add extends: override to other profiles if you want, but not inside override definition

I saw that you have released a new eas-cli (0.7.0) is the toolchain in the image updated also i.e. cocoapods 1.10.1?

yes, docs I linked are kept up to date Build server infrastructure - Expo Documentation

[twindev]

@wkozyra , thanks.
Updated my eas.json accordingly and now running my original profile i.e. “testing” with you updated image. Works perfect.
Just curious, what is the reason behind the possibility to extending the override in a build profile?
BR
/Johan

[wkozyra]

extends is intended to simplify the definition, you can define one profile with a bunch of common settings and put extend: ‘some-common-profile’ in every other profile this way you don’t need to duplicate that for every case. In the docs Configuring EAS Build with eas.json - Expo Documentation at the end there is example of that, Android build profiles release and debug both extend base profile, so when building for either release or debug values from base will also be applied.

override: { extends: override } was not correct because it states that profile override inherits values from override which inherits values from override which inherits values from override and so on, it’s an infinite loop

[twindev]

Thanks @wkozyra,
crisp answer. I have updated my eas.json with a “base” letting the other profiles extending it and I can ignore the “force” profile as you have updated the toolchain and I can go back using my thin “testing” profile.
You and your team are doing a tremendous work.
BR
/Johan