人工Cocoapods缓存 [英] Artifactory Cocoapods caching

查看:184
本文介绍了人工Cocoapods缓存的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在我们公司,我们在代理人的支持下工作.这就是为什么我们将Artifactory纳入工具链的原因之一.

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

一切似乎都看起来不错,远程存储库下载了包含所有podspec的master.tar.gz,并将podspec中的源URL更改为应该从现在开始加载的Artifactory URL.但是开始出现了问题:

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. 仅针对"git"源更改URL,只要源为"http",就不会更改源.我们遇到此问题的示例是"GoogleMaps"窗格.
  2. 如上所述,我们位于代理服务器的后面,由于我们无法绕过代理服务器,因此无法安装"GoogleMaps"广告连播.
  3. 即使我们能够做到一次,我也希望Artifactory能够像其他豆荚一样缓存豆荚.这将不能完全解决问题,但至少从现在开始,开发人员可以访问缓存的版本.但是"http"源没有被缓存,我也不知道为什么.

屏幕截图显示了如何缓存其他使用过的Pod,而不是GoogleMaps.

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.

推荐答案

这里的问题实际上不是'git'网址和'http'网址,因为Artifactory知道在提供索引时如何处理这两个网址. 它的工作方式是Artifactory实际上将它提供给客户端的索引中的URL重写为指向您的实例,然后依次下载,缓存和将Pod提供给客户端-您可以在中看到这一点.客户端在Mac上创建的本地索引存储库(通常在~/.cocoapods/repos/<repo_name>

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>

您有一个远程存储库指向github.com,因此Artifactory仅替换这些URL(http://或git://没关系),原因是远程终端的终结点是github.com,并且只能查询下载请求.

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.

以您的情况为例,例如Google Maps pod的下载URL指向https://dl.google.com/geosdk/googlemaps-ios-1.0.1.zip,因此Artifactory将不会尝试更改该URL,因为它没有指向github.

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.

我猜您真正想要的是一种与Bower的支持门户网站中进行.

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.

作为一种解决方法,我建议您手动下载构建所需的任何Pod(我想这是一个有限的列表),将它们部署到本地cocoapods存储库(或复制远程缓存中已有的存储库)存储库到本地存储库),然后将您的客户指向该存储库.
它将像从远程存储库中获取所需的Pod一样为您提供服务.

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.

这篇关于人工Cocoapods缓存的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆