Standardize Cache Flag options

[dwillist]

Description

We have received a couple different requests for functionality around the flexibility of the .build cache. These have all been implemented by adding additional flags to the pack cli. and as a result we have --cache-image and --cache-name? (pending) to specify the build cache type & name.

It feels like we might want consolidate this behavior to use more descriptive flags to make these combinations both easier to understand & extensible.

Proposed solution

Flags can be specified in a way similar to the --mount option for docker.
Possible Flags:

pack build ... --cache 'src_type=volume,src=<VOLUME-NAME>,dst_type=remote_image,dst=<IMAGE-PATH>

Additional context

• This feature should be documented somewhere

Related issues:
#1024
#665
#317

---

Update (2022-06-15)

Since this issue was opened an RFC was created and approved.

The following are tasks that need to be implemented in order to consider this issue resolved:

• Implement cache flag in pack #1458
• [cache-flag] Support build image cache #1457
• [cache-flag] Support build volume cache #1471
• [cache-flag] Support launch volume cache #1472
• [cache-flag] Support build bind cache #1473
• [cache-flag] Support launch bind cache #1474
• [cache-flag] Warn when attempting to configure launch cache image #1475

[ekcasey]

@dwillist Not sure I am following this. How can the cache src be a volume but the cache destination be a remote image?

[dwillist]

@ekcasey I would expect using the --cache-dir argument for the analyzer and restorer would allow pulling info from a mounted cache volume, then using a --cache-image flag for the exporter would cause the lifecycle to push the cache as a remote image. Am I missing something?

[ekcasey]

@dwillist ahhh gotcha. I hadn't thought about that use case (migrating caches) but I think it would work fine from a lifecycle perspective if you use the individual phase. With creator (trusted builders), this would not work because we don't accept different inputs for source cache and destination cache. creator would need to be changed to support this.

If we did something like this I think it would be important to have good defaults. As a user --cache-volume my-cache feels easier (to remember, type, autocomplete) than --cache 'src_type=volume,src=my-cache,dst_type=volume,dst=my-cache but if --cache my-volume worked (because we default src_type to volume and default the dst and dst_type to match src and src_type etc.) the proposed optionality would be great.

[jromero]

An additional use case for this feature with Bitbucket (via slack):

Links:

• https://community.atlassian.com/t5/Bitbucket-discussions/Using-CNCF-Buildpacks-on-Bitbucket-Pipelines/td-p/1516690
• https://buildpacks.io/docs/tools/pack/cli/pack_build/#options
• User-defined cache volume names #665

[jromero]

@dwillist I've started an RFC. Would love to get your contributions in there.

buildpacks/rfcs#149

[jromero]

This is ready to implement as per RFC#0091

[Nivedita-coder]

Hi @jromero @dwillist, I want to contribute to this project for GSoC 2022, can you guide me on how can I get started with this project? Thanks!

[jromero]

Setting status to blocked, since this issue was submitted to Google Summer of Code. This is scheduled to be worked on by a mentee.

[jromero]

Hi @Nivedita-coder 👋 ,

Nice to see you here. I'd be more than happy to show you around.

If you can, could you reach out to me over in the CNCF slack? My username there is @jromero. Also, we have #buildpacks-mentoring channel if you have more general questions regarding Google Summer of Code.

[rahulsurwade08]

Hey @jromero, I want to contribute for this project in GSoC 22, I have setup pack locally and already started playing with it.
Can you guide me regarding caching options that are being in evaluation and the expectations for this project?