fix(ios): make the RNSentry SPEC CHECKSUM in Podfile.lock machine-independent - #6534
Draft
alwx wants to merge 1 commit into
Draft
fix(ios): make the RNSentry SPEC CHECKSUM in Podfile.lock machine-independent#6534alwx wants to merge 1 commit into
alwx wants to merge 1 commit into
Conversation
…ependent CocoaPods stores external-source pods as an evaluated podspec JSON in Pods/Local Podspecs/ and derives the pod's SPEC CHECKSUM from that file, so the absolute ~/Library/Caches/... path we wrote into FRAMEWORK_SEARCH_PATHS leaked $HOME into Podfile.lock and made the RNSentry checksum differ per machine. Stage the cached Sentry.xcframework behind a symlink at Pods/sentry-xcframeworks/<version>/Sentry.xcframework and reference it as $(PODS_ROOT)/... instead. $(PODS_ROOT) is defined in both the per-pod and the user/aggregate xcconfigs and the link lives inside Pods/, so no Podfile-layout detection is needed and the string is identical on every machine — including machines overriding SENTRY_XCFRAMEWORK_CACHE_DIR. Fixes #6467
Contributor
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. |
Contributor
Instructions and example for changelogPlease add an entry to Example: ## Unreleased
### Fixes
- make the RNSentry SPEC CHECKSUM in Podfile.lock machine-independent ([#6534](https://github.com/getsentry/sentry-react-native/pull/6534))If none of the above apply, you can opt out of this check by adding |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📢 Type of change
📜 Description
Since #6413,
RNSentry.podspecpointsFRAMEWORK_SEARCH_PATHSat the absolute pod-install-time path of the cachedSentry.xcframework(~/Library/Caches/sentry-react-native/xcframeworks/…), which leaks$HOMEinto theRNSentrySPEC CHECKSUMwritten toPodfile.lock.This stages the cached bundle behind a machine-independent reference instead:
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) and pruning links left behind by earlier SDK versions."$(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 needed.pod install(gated onPod::Config.instance.podfile_path). Anywhere else —pod ipc spec,pod lib lint, a plainSpecification.from_file—$(PODS_ROOT)would point at an unrelated sandbox, so we fall back to the absolute cache path. Same fallback if the symlink can't be created: functional, just with a machine-specific checksum.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).Note: existing projects will see a one-time
RNSentrychecksum change inPodfile.lockon their nextpod install; after that the value is stable across developers and CI. Teams that adopted theSENTRY_XCFRAMEWORK_CACHE_DIR=/tmp/…workaround from #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.💡 Motivation and Context
Fixes #6467.
CocoaPods persists external-source pods as an evaluated podspec JSON in
Pods/Local Podspecs/RNSentry.podspec.json(ExternalSources::AbstractExternalSource#store_podspecalways callssandbox.store_podspec(name, spec, true, true)), andSpecification#checksumis the SHA1 of that file. The evaluatedpod_target_xcconfig/user_target_xcconfigtherefore carried the$HOME-dependent path straight intoPodfile.lock.Consequence: two developers (or a developer and CI) installing the exact same
@sentry/react-nativeversion get differentRNSentrychecksums, so a committedPodfile.lockflips on everypod installand teams gating CI on a clean lockfile get repeated failures. Same class of problem as react/react-native#31193.Supersedes #6474, with two fixes on top of it:
<cwd>/PodswhenPod::Configwas unavailable and still returned a$(PODS_ROOT)path. CocoaPods evaluates podspecs with the CWD set to the podspec's own directory, so that would have staged the link insidenode_modules/@sentry/react-native/while handing back a search path that dangles at build time — a hardmodule 'Sentry' not foundinstead of the safe absolute-path fallback.Pods/.💚 How did you test it?
All on macOS with CocoaPods 1.16.2 / Xcode 26.1.
Checksum determinism — reproduced CocoaPods' exact computation (
Digest::SHA1.hexdigest(spec.to_pretty_json)) while evaluating the podspec under two different$HOMEvalues:origin/main:842e4309…vs8b743fb4…— bug reproduced.43ccbce8…both times, and the two evaluated specs are byte-identical.Pods/Local Podspecs/RNSentry.podspec.jsonafter a real install contains zero/Users/…strings (down from the leaking path).SENTRY_XCFRAMEWORK_CACHE_DIR=/tmp/sentry-xcf-alt pod installyields the same checksum as without the override, and re-points the stale symlink.Real
pod installinsamples/react-native/iosandpackages/core/RNSentryCocoaTester(different Podfile depths):$(PODS_ROOT)resolves correctly in both the per-pod xcconfig (PODS_ROOT = ${SRCROOT}) and the aggregate/user xcconfig (PODS_ROOT = ${SRCROOT}/Pods). Repeated installs keep the checksum stable and the symlink survives —Installer::SandboxDirCleaneronly removes.xcodeprojchildren, target-support and header directories, so the staging dir is untouched.Builds:
xcodebuild -scheme RNSentry -sdk iphonesimulator→ BUILD SUCCEEDED (@import Sentryresolves through the symlink).xcodebuild -workspace sentryreactnativesample.xcworkspace→ BUILD SUCCEEDED;nmon the resulting debug dylib shows 168 Sentry symbols. NoSentryCocoaPod exists inPodfile.lock, so linking necessarily went through the staged path.-showBuildSettingsconfirmsFRAMEWORK_SEARCH_PATHSexpands to…/ios/Pods/sentry-xcframeworks/9.19.1/Sentry.xcframework/ios-arm64_x86_64-simulator.Edge cases:
SENTRY_USE_XCFRAMEWORK=0stages nothing and keeps theSentrypod dependency; stale/wrong symlinks and leftover version directories are recreated/pruned;rm_rfunlinks the symlink without following it (shared cache verified intact afterwards); evaluation without a Podfile falls back to the absolute path and creates no stray directories.ruby -cpasses on both files.📝 Checklist
sendDefaultPIIis enabled.Note on tests: the repo has no Ruby test infrastructure, so this is covered by the manual verification above plus the
pod installjobs insample-application.yml/native-tests.yml, which exercise the new staging path end-to-end.🔮 Next steps
Add the
ready-to-mergelabel to run the native/E2E/sample-build jobs before merging — those are the ones that exercisepod installacross RN versions and theuse_frameworks!variants.