Feature Request: Versioned Cache

[VaslD]

Checklist

• I've read the Contribution Guidelines
• I've searched for existing GitHub issues if there was such a request before.

Description

Motivation

Our team follows Git Flow practice and maintains multiple branches referring to different versions of a Pod. Especially when we decides to upgrade a Pod's major version, it takes several code reviews and assessment rounds to pin a single version across the entire repo.

Since the remote repo managed by cocoapods-binary-cache is not versioned, only a few branches in our project benefit from using a shared cache. More importantly, when someone unaware of the version change accidentally pushes to remote cache, the fun game of swapping cached version begins.

Summary

A preliminary proposal is to put cached zips in subfolders whose name matches the lock hash in Podfile.lock and Manifest.lock.

For example:

GeneratedFrameworks/Protobuf/2ccbaf193f6c65adc67745453ca0c13234c32796/Protobuf.zip

Or simply:

GeneratedFrameworks/Protobuf/2ccbaf193f6c65adc67745453ca0c13234c32796.zip

Versioned Manifest.locks can also be cached this way. Though I have no idea why this file is required as the remote cache should not care about Pods not hosted there.

[trinhngocthuyen]

Hi @VaslD,
I want to share a few thoughts on how to use the plugin together with the engineering workflow:

1/ It's more like a workflow problem in this case when engineers freely push the cache to the same repo. Ideally, we should only have one user/job that is allowed to deploy the cache. This prevents caches from being overwritten unexpectedly.

3/ It's okay to have cache miss:

• For 3rd party pods (non-development pods): It should not have that much cache miss as we do not update 3rd party pods that often, right?
• For development pods: Yes, the cache hit rate is low if we often make changes in core modules. We have a work item to enhance this, similar to what you proposed.

Although we have a roadmap to support multiple cache versions per framework, the support might not be available within 2 months from now.

While waiting for this enhancement, I would suggest exploring other areas such as adopting trunk-based development, or having separate cache repos for different (main) git branches...

Thank you!