react-native-community / react-native-circleci-orb

A CircleCI Orb to Simplify Testing your React Native App
MIT License
176 stars 80 forks source link

pod_install fails due to caching #174

Open devnev opened 1 year ago

devnev commented 1 year ago

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.

fotos commented 8 months ago

@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.

devnev commented 8 months ago

@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.

fotos commented 8 months ago

@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.