Artifactory Cocoapods caching

Question

In our company we work behind a proxy. This is one of the reasons, why we got Artifactory into our toolchain.

Everything seems to look good, the remote repository has downloaded the master.tar.gz with all the podspecs and changed the source-URLs in the podspecs to Artifactory URL where they are supposed to be loaded from now on. But there starts the problem:

1. The URLs are only changed for "git" sources, whenever the source is "http", the source is not changed. The example we have this issue with is the "GoogleMaps" pod.
2. As mentioned above, we are behind a proxy, and the installation of this pod "GoogleMaps" is not working, as we can't go around the proxy.
3. Even if we could do that once, I would expect Artifactory to cache the pod, as it does with other pods as well. This would solve the problem, not fully, but at least from now on, the developers could access the cached version. But "http" sources are not cached, and I have no idea why.

The screenshot shows how the other used pods are cached, but not the GoogleMaps one.

So if someone has experienced the same problem, and maybe even solved it, this would be amazing if you could help me.

Answer 1

The issue here is actually not 'git' urls vs. 'http' urls, as Artifactory knows how to handle both when serving the index. The way that it works is that Artifactory actually re-writes urls in the index it serves back to the client to point back to your instance, which will in turn download, cache, and serve pods back to the client - you can see this in the local index repo the client creates on your mac (usually under ~/.cocoapods/repos/<repo_name>

You have a remote repo pointing to github.com so Artifactory only replaces these urls (http:// or git:// , it doesn't matter) - the reason being that the remote's endpoint is github.com and it can only query it for download requests.

In your case, the Google Maps pod's download url points to https://dl.google.com/geosdk/googlemaps-ios-1.0.1.zip for example, so Artifactory will not attempt to change the url because it does not point to github.

I guess what you're really looking for is a mechanism similar to what we do with Bower's dependency re-write - but this functionallity is not yet available for Cocoapods. You are more than welcome to submit a feature request for it though, you can do it in our support portal.

As a workaround I would suggest that you manually download whatever pods you need for your build (i'm guessing it's a finite list) deploy them to a local cocoapods repository (or copy over the ones you already have from the remote cache repository to the local one), and point your clients to it.
It will be able to serve the required pods as if you got them from the remote repo.