Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pod_install fails due to caching #174

Open
devnev opened this issue Jul 19, 2023 · 3 comments
Open

pod_install fails due to caching #174

devnev opened this issue Jul 19, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@devnev
Copy link
Contributor

devnev commented Jul 19, 2023

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 devnev added the bug Something isn't working label Jul 19, 2023
@fotos
Copy link
Collaborator

fotos commented Feb 3, 2024

@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
Copy link
Contributor Author

devnev commented Feb 6, 2024

@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
Copy link
Collaborator

fotos commented Feb 10, 2024

@devnev I took a closer look – this looks like a bug in react-native? Check out issue facebook/react-native#36945 and facebook/react-native#36945 (comment). 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants