You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Platforms like pack allow storing the cache layers in a remote registry. kpack should allow doing the same for clusters that don't have PVCs or for more flexibility with caching in general. This might require a spec change from spec.cacheSize to spec.cache which looks like -
It would also be great if the two caching strategies can be used in conjunction. i.e. being able to have local builds as fast as possible, while still allowing some level of caching for multi-clusters setup, or when the cache needs to be busted.
It would also be great if the two caching strategies can be used in conjunction. i.e. being able to have local builds as fast as possible, while still allowing some level of caching for multi-clusters setup, or when the cache needs to be busted.
@divoxx Interesting, idea! I think that might require a change to the underlying cloud native buildpack project to either support multiple types of cache or some cache hierarchy. Would you be interested in bringing that up in Buildpacks slack or Buildpacks working group?
As dicussed in slack at https://buildpacks.slack.com/archives/CQ10WHMT4/p1613732146033900
TL;DR -
Platforms like
pack
allow storing the cache layers in a remote registry.kpack
should allow doing the same for clusters that don't have PVCs or for more flexibility with caching in general. This might require a spec change fromspec.cacheSize
tospec.cache
which looks like -Something like:
and:
The text was updated successfully, but these errors were encountered: