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.
Related
I am trying the caching features of tuist (https://tuist.io) using one of the demos provided on Github, the app_with_spm_dependencies (https://github.com/tuist/tuist/tree/main/projects/tuist/fixtures/app_with_spm_dependencies). I was trying to see the power of caching dependencies using tuist. My approach was running the commands tuist fetch and I got here a warning about some watch target, but it shouldn't invalidate the iOS simulator targets, tuist cache warm, and finally tuist generate. I didn't see any changes in the build times. Checking the ~/.tuist/Cache/BuildCache shows an empty folder. The command tuist cache print-hashes outputs a list of hashes of the targets and external dependencies of this demo project, therefore I can assume some hashes were created. But where is the cache stored in this case? Why is the cache not being used on the tuist generated project file in Xcode 14?
I saw the compile steps for each dependency so I am sure everything is being built from scratch.
This is all down to expectations. tuist cache is nothing more than what a clean build on the Xcode project would do: download dependencies into your Build folder and compile them to be used by your code. Each cleancommand erases the Build folder, which in turn results in an empty cache. So, it turns out that the caching feature, in practice, would be the same as keeping the Build folder intact.
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.
I am starting using Bitrise as the CI for my iOS app but I'm on the free version, so the build have to take 10 minutes or less.
The main issue is when Bitrise builds my Carthage dependencies, is there a way where I can prebuild it in local, push everything to my repo so I can completely avoid the Carthage step?
At the moment I'm using carthage bootstrap. I have also tried carthage update --cache-builds.
Thanks
Use rome https://github.com/tmspzz/Rome, this provides a cloud storage based Carthage cache, your Carthage step will pull pre-built binaries from your choice of cloud storage (S3 for instance).
I need to up TeamCity CI/CD for my iOS project. I'm using Carthage for dependency management.
I understood that performing carthage update for each build is a bad idea. A build-agent will be rebuilding frameworks for every new build. It's very time-consuming operation.
Is there any approach for the caching my dependencies for speedup a build?
Possible approach would be setting up a separate build configuration (e.g.,"Producer") that executes carthage update (whenever needed), then uploads zipped Carthage/Build to build server. Other build configurations for your project should have an artifact dependency on "Producer" and fetch binaries back to Carthage/Build
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?