Cocoapods: Pushing interdependent Cocoapods to Trunk - issue with eventual consistency

[iartemiev]

• [x] I've read and understood the CONTRIBUTING guidelines and have done my best effort to follow.

Report

(Asked this question on SO originally, but it didn't get any traction: https://stackoverflow.com/q/59656454/322720)

Interested if someone knows of a way to effectively push interdependent pods to the CocoaPods Trunk since the Repo CDN update.

What did you do?

Let's say I have 2 pods in a monorepo: pod1 and pod2 where pod1 is listed as a dependency for pod2.

A script in our CI pipeline increments the versions of the pods and dependencies in the respective spec files.

pod1.podspec:

s.version = 1.0.1

pod2.podspec:

s.version = 1.4.4
s.dependency 'pod1', '1.0.1'

The script then pushes the pods to Trunk one after the other:

1. pod push pod1.podspec - pushes to Trunk successfully under the new version (1.0.1)
2. pod push pod2.podspec - fails validation and errors out with e.g.

If I wait 5 mins and then run pod push pod2.podspec again, it succeeds.

It would appear that objects in the Trunk Repo CDN have a TTL of ~ 5 mins.

It would be possible to have the deploy script wait 5 minutes after each pod push but that is suboptimal, especially for monorepos with many interdependent pods. I've thought about loosening the version requirement, e.g. s.dependency 'pod1', '~> 1.0.1' but that's not always a viable option either.

I've tried running pod repo update between the pushes but that had no effect.

What did you expect to happen?

Expected both of the pods to get pushed up to Trunk successfully.

What happened instead?

The second pod push errored out with the following error:

-> pod2 (1.4.4)
- ERROR | [iOS] unknown: Encountered an unknown error (CocoaPods could not find compatible versions for pod "pod1":
In Podfile:
    pod2 was resolved to 1.4.4, which depends on
      pod1 (= 1.0.1)

CocoaPods Environment

Stack

This is from our CI environment specifically. We've been encountering the same issue locally as well (same version of CocoaPods).

   CocoaPods : 1.8.4
        Ruby : ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19]
    RubyGems : 3.0.3
        Host : Mac OS X 10.15 (19A602)
       Xcode : 11.2.1 (11B500)
         Git : git version 2.24.0
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib
Repositories :

Installation Source

Executable Path: /usr/local/bin/pod

Plugins

cocoapods-deintegrate : 1.0.4
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.1.0
cocoapods-trunk       : 1.4.1
cocoapods-try         : 1.1.0

[dnkoutso]

cc @igor-makarov to make it faster. In the meantime you can use the git based repo solution as CocoaPods always used.

[igor-makarov]

Yeah, I don't think there's any way to speed it up, we're dependent on several free services here.

If I recall, @paulb777 you fixed this by adding delays? Can you comment?

[iartemiev]

@dnkoutso @igor-makarov thank you for the responses!

Do you know if pushing to the git-based repo directly will remain an option for the foreseeable future? Or are there plans to deprecate that in favor of pushing to the CDN?

We've considered adding a 5 min delay step in between the pod push steps but we have multiple interdependent pods in some of our monorepos, in which case the delays start to really add up and degrade our CD workflow.

[igor-makarov]

There's technically no way to deprecate the git repo - it's where the CDN site gets generated from!

[paulb777]

We haven't implemented a solution yet besides manual retries, but the delays can be up to 10 minutes.

[iartemiev]

That's fair. I just didn't know if perhaps there were plans to take the repo private and only expose the CDN to users. But if not - that's great, and we'll just use the git repo from now on.

Thanks again!

[orta]

pod trunk push could prioritise using the git repo instead of the CDN for trunk (if it was already set up), which would mean you could get the same speeds as old.

The data on trunk, and in git is still instant

[iartemiev]

Re-opening this due to the issues with the proposed solution (per #9502)

Would really appreciate a solution other than waiting 10 minutes between pushes. We have dozens of pods in AWS iOS SDK, with numerous interdependencies.

[iartemiev]

@paulb777 @dnkoutso ^

[igor-makarov]

@iartemiev why is your SDK structured this way?

This is an extremely uncommon use case and there are multiple performance issues I can see with it besides the spec repo consistency. For example, users using several of the pods will clone the entire repo for each pod.

In any case, these are the limitations of the Netlify platform and because CP is a free, minimally sponsored, open-source project, there's nothing we can do about it.

[iartemiev]

@igor-makarov all we're asking for is an option to push to the git repo directly, instead of to the CDN, i.e. the way CocoaPods functioned by default before version 1.8. For example, adding a flag like pod trunk push --skip-cdn or something along those lines.

[iartemiev]

@igor-makarov also, I understand that most projects don't have as many pods as the AWS SDK. However, this is an issue for repos with any number of pods > 1 that depend on each other.

[dnkoutso]

Removing 1.10 milestone because this issue will be fixed for many more CocoaPods version once the trunk PR is merged and released.

[dnkoutso]

Fix was merged in https://github.com/CocoaPods/cocoapods-trunk/pull/147

[paulb777]

And cocoapods-trunk 1.5.0 has now released with the fix. Thanks @dnkoutso!

[priteshrnandgaonkar]

A noob question, how can I use cocoapod-trunk 1.5.0 with cocoapod version 1.9.1. I installed cocoapod-trunk , by doing gem install. But how do I make cocoapod use that trunk version.

[dnkoutso]

gem update cocoapods-trunk

[lucatorella]

I removed the sleep(600) and I'm using the new --synchronous options. It works great in most cases, at least in the past, but recently it's failing like 50% of the time.