CDNSource: Use a more compact, sharded index retrieving for the pod versions

[igor-makarov]

So this is the new iteration of CDNSource. It no longer relies on per-pod index.txt files, but similar to RubyGems, utilizes concentrated version index files.

The per-shard files are named all_pods_versions_9_a_4.txt and are assumed to be located in the root of the repo. The content of each file is of the following format:

PodName/1.0.3/1.1/1.1.1/1.1.2/1.1.3/1.1.4

This change reduces the amount of deployment work down to 2 minutes on Netlify and there are as many files as there are shards (4,096).

I've also added to CDNSource the capability to follow redirects.

I've updated the tests and I believe new tests aren't necessary at this moment.

Netlify deployment has been completed and is possible and running.

[igor-makarov]

I've been talking to Netlify about an open source license and they seem to be okay with hosting the CocoaPods spec repo cache.

This is their open source program page.

Additionally, proxying Netlify through jsDelivr would work as well. I've talked to them as well and they handle all the specifics correctly.

[amorde]

I like this version better than the previous draft since its a bit more compact 👍

[amorde]

can Pods have '/' in their name? I'm not 100% if they can, but we might have to think about escaping things here

[igor-makarov]

As far as I managed to find, there are no pods with slashes. While theoretically possible, it's pretty hard to create a file with a slash in the name.

I don't know if pod linting checks for it.

[igor-makarov]

Also, I think Pod/Name is reserved for subspecs.

[amorde]

Yeah that sounds right

[igor-makarov]

@amorde Keep in mind that while being more compact and performant (entire zip is only 750KB), using it will generate more CDN traffic, as each podspec publish will cause the entire index to get dirty.

[amorde]

Yup was actually referring to this PR when it was a draft and had the compact index but the versions all on separate lines. Good point though on the traffic. Maybe there's a middle ground in which we separate this into smaller chunks, but not as many chunks as before.

What if we did something similar to the spec repo sharing, and had an index per starting character (ex. a-pods.txt, b-pods.txt, 1-pods.txt)?

[igor-makarov]

Considering the random-like nature of the shard hash function, and the fact that most projects have multiple pods, I don't think sharding the compact index would help much. Unless you shard it all the way, but that might cause problems when building on Netlify.

Ultimately, this index will be downloaded only when creating and updating a repo. Additionally, jsDelivr said they don't have a problem being the CDN in front of Netlify.

[igor-makarov]

Alright! I've tested deploying full sharded indexes on Netlify and it works okay. Turns out they don't have a problem with ~4k files, only ~700k files. 🙃
This new version has a text file for each shard, named like all_pods_versions_9_a_4.txt where the suffix is the shard path. Each file is around 1KB, and while my total (for a project with 30 pods) was 300KB - these aren't expected to churn as much!

[igor-makarov]

Now that Netlify deployment is up, this can be merged safely.

[igor-makarov]

I've updated the original PR comment to reflect the code that's being PR'd.

[igor-makarov]

Awesome! 💪

[dnkoutso]

Cherry-picked to 1-7-stable here.