fix(ios): make the RNSentry SPEC CHECKSUM in Podfile.lock machine-independent#6474
fix(ios): make the RNSentry SPEC CHECKSUM in Podfile.lock machine-independent#6474Cryptoteep wants to merge 2 commits into
Conversation
FRAMEWORK_SEARCH_PATHS pointed at the absolute per-user xcframework cache path (~/Library/Caches/...), and everything in the evaluated spec feeds the SPEC CHECKSUM CocoaPods writes into Podfile.lock — so the checksum differed per machine and the lockfile churned on every pod install. Stage the cached bundle behind a Pods/sentry-xcframeworks/<version> symlink and reference it as $(PODS_ROOT)/sentry-xcframeworks/..., which is the same string on every machine. If the symlink cannot be created, fall back to the absolute path (previous behaviour). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Semver Impact of This PR⚪ None (no version bump detected) 📋 Changelog PreviewThis is how your changes will appear in the changelog.
🤖 This preview updates automatically when you update the PR. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit d3276eb. Configure here.
| # (e.g. `SENTRY_XCFRAMEWORK_CACHE_DIR` changed between installs). | ||
| unless File.symlink?(link_path) && File.readlink(link_path) == xcframework_dir | ||
| FileUtils.rm_rf(link_path) | ||
| File.symlink(xcframework_dir, link_path) |
There was a problem hiding this comment.
Relative cache path breaks xcframework symlink
Medium Severity
When SENTRY_XCFRAMEWORK_CACHE_DIR is a relative path, ensure_sentry_xcframework still resolves the xcframework using the Podfile working directory, but File.symlink treats a relative target as relative to the staging directory under Pods/sentry-xcframeworks/…. The symlink can point at the wrong location while staging still returns the stable $(PODS_ROOT) reference, so pod install succeeds and Xcode later fails to find Sentry.
Reviewed by Cursor Bugbot for commit d3276eb. Configure here.
|
Thank you for the fix, @Cryptoteep! can you update the sentry-utils.rb as suggested above? |
| File.symlink(xcframework_dir, link_path) | ||
| end | ||
|
|
||
| "$(PODS_ROOT)/sentry-xcframeworks/#{version}/#{product}.xcframework" |
There was a problem hiding this comment.
a small thing: could you please use ${PODS_ROOT} to match CocoaPods' generated xcconfig style? with {} instead of ()
2 participants
Closes #6467
The problem
Since #6413,
RNSentry.podspecpointsFRAMEWORK_SEARCH_PATHSat the absolute pod-install-time path of the cachedSentry.xcframework(~/Library/Caches/sentry-react-native/xcframeworks/…). CocoaPods computes theSPEC CHECKSUMit writes intoPodfile.lockover the evaluated spec — including those xcconfig values — so the$HOMEcomponent leaks into the checksum. Two machines installing the same SDK version get differentRNSentrychecksums, and a committedPodfile.lockflips on everypod install(full analysis in #6467).The fix
Stage the cached bundle behind a machine-independent reference instead of putting the absolute path into the spec:
stage_sentry_xcframework_in_pods(new,sentry_utils.rb) symlinksPods/sentry-xcframeworks/<sentry-cocoa version>/Sentry.xcframework→ the cached bundle, recreating the link when it's missing or stale (e.g.SENTRY_XCFRAMEWORK_CACHE_DIRchanged between installs)."$(PODS_ROOT)/sentry-xcframeworks/<version>/Sentry.xcframework/<slice>"intoFRAMEWORK_SEARCH_PATHS— the same string on every machine, so the checksum is deterministic.$(PODS_ROOT)is defined in both per-pod and user/aggregate xcconfigs (unlike$(PODS_TARGET_SRCROOT)), and because the link lives insidePods/there is no Podfile-layout detection — the objections that originally motivated the absolute path don't apply to this shape.The download/cache/SHA256-verification flow is unchanged; the cache stays in
~/Library/Caches(still shared across projects, still safe under pnpm's read-only store and Yarn PnP).Notes
RNSentrychecksum change inPodfile.lockon their nextpod install; after that the value is stable across developers and CI.SENTRY_XCFRAMEWORK_CACHE_DIR=/tmp/…workaround from iOS: RNSentry SPEC CHECKSUM is machine-specific (absolute xcframework path in FRAMEWORK_SEARCH_PATHS) → Podfile.lock churn across devs/CI #6467 can drop it — and mixed setups (some machines with the override, some without) now converge on the same checksum, since the override no longer appears in the spec.pod installjobs exercise the new staging path end-to-end. I don't have a macOS machine at hand, so I couldn't run the two-$HOME determinism check from the issue locally — happy to adjust if anything shakes out in CI.🤖 Generated with Claude Code