Cocoapods embed a step in the build phase to check if the Pods folder is in sync with the versions in Podfile.lock. This blocks the developer to work with the stale versions of the Pod with the following error:
error: The sandbox is not in sync with the Podfile.lock. Run 'pod
install' or update your CocoaPods installation.
Carthage has Cartfile.resolved, but how is it used to check if the Carthage Builds are fresh vs stale? Is it something that has to be manually enforced via some script?
Afaik the Carthage guides do not mention this topic at all. Usually you will be informed via failing compilation that a certain framework is not found, e.g. if you switched to a new branch where a new feature is implemented that needs framework XYZ. Then you know you have to run carthage bootstrap.
We have a script that runs so fast that you could even place it into the git hooks so it runs automatically after switching branches. The carthage part just cann the following command:
carthage bootstrap --use-ssh --use-xcframeworks --cache-builds
It makes sure carthage is up to date and it is fast since it uses cached builds. Runs fine for several years now.
Related
I am currently running Carthage dependency manager for iOS, and I am having a hard time clearing the cache when running it over Azure Pipeline. This is what I am calling to build all the dependencies for the project.
carthage bootstrap --platform ios --verbose --new-resolver --use-xcframeworks
I have tried removing the cache based on the logs as following:
/Users/*****/Library/Caches/org.carthage.CarthageKit
However, it still grabs the cached version of the repo and fails. I have tried building the same project locally and it works and builds fine.
I have also tried to clean the workspace as part of the pool job, but still, it doesn't clean the cache.
Any help in this context is much appreciated.
I'm trying to build my nativescript app on iOS.
I have brand new MacMini with fresh system and all stuff like xcode, etc.
My app builds without any warnings on android - not checked android build on Mac.
When i try to run my app on emulator i have an error saying:
Analyzing dependencies
[!] There are multiple dependencies with different sources for `Socket.IO-Client-Swift` in `Podfile`:
- Socket.IO-Client-Swift (from `https://github.com/triniwiz/socket.io-client-swift.git`)
- Socket.IO-Client-Swift (~> 12.1.3)
'pod install' command failed.
Tried to remove one of the dependency from pod file but without any luck - it brings back during build.
What should i do?
After updating my dependencies, I also ran into an issue with Cocopods, although, not exactly the same. In my case, running pod repo update from within platforms/ios solved my problem. In short, there had been updates that my local pod spec repo wasn't aware of and it was getting "confused". I'm not sure if this will ultimately solve your specific problem, but it's fairly quick to do and, at least, won't hurt anything.
Good luck!
I have created a swift (iOS/MacOS) library on CocoaPods (BillboardSwiftLibrary). Generally, it has its assets and Classes folders which contain the source files.
I want my library to support Swift Package Manager, so I moved the source files from the Classes folder into a Sources folder outside the pod. However, they are still accessible from the Development pods.
Now my library won't build for Cocoapods launch but compiles for Swift Package Manager, I get the error below when I run pod lib lint BillboardSwiftLibrary.podspec
ERROR | file patterns: The source_files pattern did not match any
file.
I wrote a long series from scratch about "Creating iOS framework with CocoaPods, Carthage, SPM support and Travis for running test and Fastlane for release automation" on Medium. I hope it helps.
Creating Swift framework is easy but adding CocoaPods, Carthage and Swift Package Manager support at the same time can sounds like scary in the first place. In addition to that adding Travis to run test for all commits and adding Fastlane to automate release processes for all dependency managers looks like a horror movie. But don’t be afraid. After you finished this series, you can easily create your own Swift frameworks that uses all these tools to make it perfect!
Part 1 — Create CocoaPod and release it.: You will create your own CocoaPod and release it.
Part 2 — Add Carthage support: Your CocoaPod that is created and released at Part 1 will be installed via Carthage.
Part 3 — Add Swift Package Manager support: Your CocoaPod that is created and released at Part 1 will be installed via Swift Package Manager.
Part 4 — Integrate Travis to build example project and run tests for framework: Your framework that can be installed via CocoaPods, Carthage and Swift Package Manager runs tests automatically on Travis for every push on GitHub.
Part 5 — Integrate Fastlane to automate release processes by running just one line of command.:
Every time you want to release new version of your framework via CocoaPods, Carthage and Swift Package Manager, you have to go through following steps:
1- Implement changes for new version
2- Run tests to be sure they are working
3- Commit and push changes for new version.
4- Tag new version to git
git tag 0.1.1
git push origin 0.1.1
Carthage and Swift Package Manager installs your framework from GitHub. If you configure your framework correctly, it can be installed via Carthage or Swift Package Manager after this step. However, CocoaPods has 4 more steps to complete release processes.
5- Increment podspec version => i.e. s.version = '0.1.1'
6- Validate local podspec:
pod lib lint ODCustomFramework.podspec
7- Validate pod for release
pod spec lint ODCustomFramework.podspec
8- Release
pod trunk push ODCustomFramework.podspec
After Travis and Fastlane integration, steps 2, 4, 5, 6, 7 and 8 are automated and those steps are no longer needed to repeat every time you want to release new version.
1- Implement changes for new version
2- Commit and push changes for new version.
3- Travis runs tests automatically after every push.
4- Run following fastlane command to automate all release processes. (step 4, 5, 6, 7, 8)
exec fastlane major | minor | patch
From #Larme's comment, I found the answer.
In your podspec file, change the location of your classes to the sources folder.
So changed my s.source_files from to BillboardSwiftLibrary/Classes/**/* to Sources/**/* and pod lib lint BillboardSwiftLibrary.podspec worked fine.
I'm trying to convert an open source project that I do not own to use Carthage so I can include it as a dependency. I added a new scheme and have made that scheme Shared. I checked it in to my local git repo of the source. This is in my Cartfile:
git "file:///Users/crystaltwix/Projects/plcrashreporter" "shared-scheme"
When I try to run
carthage update --platform iOS
I do see that Carthage checks out plcrashreporter with the correct git hash, but the error I get is
*** Skipped building plcrashreporter due to the error:
Dependency "plcrashreporter" has no shared framework schemes for any of the platforms: iOS
Is there something else that needs to be done in order to have a framework be available through Carthage?
I did integrate the plcrashreporter framework with Carthage, but since the project is quite obsolete, I had to fork a pull request which is this one:
https://github.com/plausiblelabs/plcrashreporter/pull/9
as you can see, there are many commits there (#34), some related specifically to Carthage, some others for cleanup and fixing the targets.
You can find the repo here:
https://github.com/feelform/plcrashreporter
My test (you may find it here) has the following:
Cartfile: github "feelform/plcrashreporter"
In build settings, Run Script:
/bin/sh: /usr/local/bin/carthage copy-frameworks
Input files: $(SRCROOT)/Carthage/Build/iOS/CrashReporter.framework
Output files:$(BUILT_PRODUCTS_DIR)/$(FRAMEWORKS_FOLDER_PATH)/CrashReporter.framework
I work on a team that is an iOS contractor for a larger company. We are helping the large company build a iOS app with Xcode and we use Cocoapods to manage our dependencies in the project. However, the large company has internal Cocoapods that are hosted behind their firewall that we, the contractors, cannot see or touch. This produces many issues for the developers outside the firewall not the least of which is that 'pod update' and 'pod install' both fail with:
Update all pods
Cloning spec repo `xxx-podName` from `https://xxxx.git`
[!] Unable to add a source with url `https://xxxxx.git` named `xxx-podName`.
You can try adding it manually in `~/.cocoapods/repos` or via `pod repo add`.
Because these repos/pods rarely are changed outside of our project we don't usually need to actually pull down new/updated code from them. Still there are many important side-effects from the 'pod' commands that our team would like to be able to accomplish, such as the re-structuring/regeneration of the workspace and project files along with other the auto-magic processes that occur when 'update' or 'install' are run (such as the building of shell scripts).
Is there a 'contactless' way to rebuild or create the correct project/target/workspace structuring for an Xcode project with cocoapods that can succeed even if the machine running the command cannot access the hosted pods?