Last week I ran a build and it failed because one of my podspecs was not yet in the cached repo - it had been published just that day. I reran my build at a later time and it passed, presumably because the cache had been updated from the master Cocoapods repo with the podspec I needed.
What is the best practice to avoid such failures in the future? Should I use the --repo-update option when I do my pod install, to get the latest specs that aren’t yet in the cache, or is there a better way?
(Also, just for my curiosity, how frequently is CircleCI’s podspec cache updated from the master repo?)
Hey! - The CocoaPods repo cache is updated roughly every 30 mins, which is usually frequent enough to only miss the last 6 pushes to the Specs repo.
If you find yourself in a position where this is a frequent problem (such as pushing and updating an internally maintained pod regularly), I’d highly recommend checking in your Pods/ directory, as this frequently saves a fair amount of CI time, alongside its other benefits.
@DanToml Is there a recommended way to save time (it takes roughly 3-4 minutes) even on loading the specs if nothing changed, meaning Podfile and Manifest lock files match? I’ve tried only downloading specs from the mirror if those file differ but then pod install starts to clone the main specs repo, as I guess there is none in a workspace. And I’m not sure that just including ~/.cocoapods/repo is a safe thing to do here.
I’m not familiar with this technology, but would I be right in thinking that this downloads library dependencies based on one of the files you mention? If so, it sounds like the CircleCI restore_cache and save_cache devices would be helpful here - you can do a checksum on that file, so that it only re-downloads if the file changes.