Repository navigation
Update the pods a committed Podfile.lock can no longer hold, in the guest only - #3
Merged
Merged
Conversation
…uest only A plugin upgrade on the host can ask for a pod the committed Podfile.lock pins at an older version: @capacitor/camera 8.2.4 wants IONCameraLib 2.x where the lock holds 1.0.4. `pod install` keeps every pinned version, so it stops and names the pod instead of refreshing anything, and the lock-drift flow the design describes was never reached, because it only fires when `pod install` itself rewrites the lock. A Linux host cannot run CocoaPods, so nothing there could move the lock either. The guest recipe now runs `pod install`, and on failure reads the pods CocoaPods names in its own "could not find compatible versions" lines, limited to the characters a pod name can hold, and retries with `pod update` for exactly those, as CocoaPods advises. The lock then differs from the committed one, the existing marker reports it, and the test build step offers the refreshed lock for adoption. Any other failure still fails the build, and a project with no committed lock is left to plain `pod install`. Verified with a fixture `pod` on Linux and under bash 3.2. The native Mac path keeps its `--deployment` install: that host has CocoaPods, and the path refuses by design to alter the host project.
The macOS half of CI failed the Android HTTP fixture with "File exists" from create_dir, on a change that had not touched it. Every test fixture named its temp directory by the process id and a nanosecond timestamp; a macOS clock ticks in microseconds, and a test binary creates fixtures on many threads at once, so two born in the same instant took the same name. Linux clocks are fine-grained enough that it had never shown there. test_scripts::fixture_dir names a directory by the process id and a process-wide counter and creates it. Every test fixture in the crate uses it now, and none names a directory by a clock any more.
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.
The unsigned test build failed at Resolving CocoaPods with "could not find compatible versions for pod IONCameraLib": the committed
ios/App/Podfile.lockpins 1.0.4 while the project's@capacitor/camera8.2.4 wants 2.x.pod installkeeps every pinned version, so it stops and names the pod rather than refreshing the lock. The lock-drift flow the design record describes, a refreshed guest lock offered for adoption, was never reached because it only fires whenpod installitself rewrites the lock. A Linux host cannot run CocoaPods, socap sync iosthere cannot move the lock either.The guest recipe now runs
pod install, and on failure reads the pods CocoaPods names in its own message, limited to the characters a pod name can hold, and retries withpod updatefor exactly those. The lock then differs from the committed one, the existing marker reports it, and the test build step offers the refreshed lock for adoption. Any other failure still fails the build, and a project with no committed lock is left to plainpod install.The native Mac path keeps its
--deploymentinstall: that host has CocoaPods, and the path refuses by design to alter the host project.Tests: recipe rendering for locked and open projects, and a fixture
podrun through the rendered script for the conflict, an unrelated failure, and a clean install. The rendered script was also run under bash 3.2. Recorded in the design record's test build section and the issue ledger.