react-native-circleci-orb
react-native-circleci-orb copied to clipboard
pod_install fails due to caching
Orb version
7.1.1
What happened
After doing upgrades including pod updates, iOS build worked fine locally, but the orb's pod_install command failed in CI
Output from "Restoring cache" step:
No cache is found for key: 3-cache-pods-NLpM_KWW5Olan7ZcJcqvoylIMtyleeOmIhlZMZ8xtR0=
Found a cache from build 718 at 3-cache-pods
Size: 525 MiB
Cached paths:
* /Users/distiller/project/ios/Pods
Downloading cache archive...
Unarchiving cache...
Output from "Install CocoaPods" step:
#!/bin/bash --login -eo pipefail
cd ios && pod install && cd -
Using firebase.json from '/Users/distiller/project/firebase.json'
Adding a custom script phase for Pod RNFBApp: [RNFB] Core Configuration
Adding a custom script phase for Pod RNFBCrashlytics: [RNFB] Crashlytics Configuration
Auto-linking React Native modules for target `Sensat`: A0Auth0, RNBootSplash, RNCAsyncStorage, RNCMaskedView, RNDeviceInfo, RNExitApp, RNFBApp, RNFBCrashlytics, RNFBDynamicLinks, RNFBMessaging, RNFS, RNFastImage, RNGestureHandler, RNImageCropPicker, RNLocalize, RNPermissions, RNReanimated, RNSVG, RNScreens, RNSensors, ReactNativeExceptionHandler, VisionCamera, lottie-ios, lottie-react-native, react-native-blur, react-native-config, react-native-geolocation-service, react-native-heic-converter, react-native-mmkv, react-native-netinfo, react-native-safe-area-context, react-native-sensitive-info, react-native-webview, segment-analytics-react-native, and sovran-react-native
Framework build type is static library
[Hermes] Downloading Hermes source code for commit 49794cfc7c81fb8f69fd60c3bbf85a7480cc5a77
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 9774k 0 9774k 0 0 4179k 0 --:--:-- 0:00:02 --:--:-- 4961k
[Hermes] Expanding Hermes tarball for commit 49794cfc7c81fb8f69fd60c3bbf85a7480cc5a77
[Hermes] Using pre-built HermesC
[Codegen] Generating ./build/generated/ios/React-Codegen.podspec.json
Analyzing dependencies
[Codegen] Found FBReactNativeSpec
[Codegen] Found rncore
Adding spec repo `trunk` with CDN `https://cdn.cocoapods.org/`
[!] CocoaPods could not find compatible versions for pod "hermes-engine":
In snapshot (Podfile.lock):
hermes-engine (from `../node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec`)
In Podfile:
hermes-engine (from `../node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec`)
It seems like you've changed the version of the dependency `hermes-engine` and it differs from the version stored in `Pods/Local Podspecs`.
You should run `pod update hermes-engine --no-repo-update` to apply changes made locally.
Exited with code exit status 1
CircleCI received exit code 1
This continued until we bumped the CACHE_KEY.
Speculation
AFAICT, the issue is that there's a bunch of outdated podspecs. I noticed that In the cache restore step, it shows that there's no cache for the exact Podfile.lock hash, but it can fall back to prefix-based matching to some previous build with a completely different Podfile.lock. Relevant CircleCI docs on restore_cache:
A key is searched against existing keys as a prefix. Note: When there are multiple matches, the most recent match will be used, even if there is a more precise match.
But I don't fully understand the pod system, and the podspecs seem to be in node_modules, so there might be more to it.
Expected behavior
Doesn't fail the build by when using an old cache.
@devnev I added the ability to bust the pod install caches in #142 (a long time ago).
You can bump the CACHE_VERSION environment variable to bust the cache in such cases. I'm not sure removing the fallback is a good idea but if you have a strong opinion feel free to open a PR for it.
@fotos what are your reservations regarding removing the fallback? It mainly seems like a hurdle as noted in this issue - it's normal for caches to get invalidated when doing upgrades, but having upgrades break due to caching seems undesirable.
@devnev I took a closer look – this looks like a bug in react-native? Check out issue facebook/react-native#36945 and https://github.com/facebook/react-native/issues/36945#issuecomment-1527512089. In other words falling back to the previous cache should work.
As I said before I don't have a strong opinion so feel free to open a PR to remove the fallback cache.