CocoaPods timing out

We are aware of sporadic issues with CocoaPods timing out. While our SRE team is working on a long term fix, if your build experiences problems communicating with CocoaPods we would recommend the following workaround:

  1. Add ~/.cocoapods/repos/master to your cached folders in circle.yml
  2. Rebuild without cache in the event that CocoaPods fails
1 Like

we’re already doing that, but it seems like on some builds the cache isn’t working and the master spec repo gets updated again, which sometimes times out (we’re still trying to get on top of this - currently trying increasing the timeout from 10 mins to 60 as a hack)

will part of your long term solution be to provide a (very) recent spec repo in ~/.cocoapods as part of the container image? :pray:

Here’s an example of what to put in circle.yml if you’re experiencing this issue:

    - bundle exec pod install --verbose:
        timeout: 1800
    -  "~/.cocoapods/repos/master"

i’ve done all that already. i’ve taken OUT the cache step, because of how long it was taking (although since i put in a 60 min timeout on the pod install step it was working better). the solution i’ve come to now is to use the pod check gem for cocoapods and only run pod install if i need to. this means i don’t need to cache the pod spec repo, since we hardly ever need to update it, and i’ll just wear the 25 minute update for those times that i do.

our circle.yml is now basically a post checkout script like the following (not sure if we should make it a dependency instead of post-checkout phase, or what the difference would be?):

gem install bundler
bundle install
bundle exec match development --readonly
bundle exec pod check || bundle exec pod install || bundle exec pod install --repo-update --verbose

The issues with Cocoapods is being worked on upstream. For anyone interested in following along:

thanks tom, i hadn’t seen that issue. however, i would like to point out that things have been a little intermittent, and i don’t think it’s all github/cocoapods to blame. we have used the caching solution you posted above, yet maybe ever 3 or 4 builds, the spec repo that comes out of our cache seems invalid, and the repo update takes 25 mins. yet on other builds, it is very quick. are you saying that this difference (< 1 min, > 25 mins) is all to do with cocoapods/github? or is there some issue with our cache?

i like my solution above better, since our Podfile.lock only changes sporadically, so most of the time we don’t even need pod install

i’m happy to spend 25 mins update the spec repo IF we need it (and that means, we’ve updated some pods in our project AND those pod versions don’t already exist in the local spec repo).

i think the best solution would be if the circle ci image included a daily cache of the master spec repo by default in ~/.cocoapods and then you could use something like my script above to run your dependency step. the only time it would be slow would be if someone updated to a pod that was only added to the podspec repo < 24 hours ago (unlikely)

Yep, we have been seeing the issue that @tristandl mentioned as well. There are two issues at the moment:

  1. The cache is randomly corrupt for some builds and, as a result, the pod install step triggers pod setup to download the repo, thus taking forever since the cache was not used

  2. The Restoring cache step has been randomly taking a really long time for some builds, with a duration of ~12 minutes instead of ~1-2 minutes

If those two issues were resolved, then the caching workaround should be sufficient until the CocoaPods team can get things straightened out. A bonus would be having the containers come pre-loaded with the master repo, to shave off the cache restoring/saving times.

1 Like

We are getting the dreaded “error 65” from xcodebuild sometimes, which automatically triggers a rebuild without cache, I think that’s where our cache is being invalidated.

I would really like to see the master pod spec repo mirrored into the vm on a ~daily basis - that would be so awesome, and would really save on bandwidth/server load at github. And it would make pod install fly! The caching mechanism in circle is sub-optimal compared with actually putting it in the vm image, since it takes about 4 minutes to extract the cache, which on it’s own would be ok, except for the fact that the cache is often ignored/corrupt as you say…

The spec repo isn’t a build artefact, there’s no sense in creating it during a build and then caching it. Given that it’s 850mb a mirror that’s preloaded in the image would be well worth it.