This PR adds the option cacheVolumeNames to the spring-boot maven/gradle plugins, which allows the specification of custom build cache volume names.

At the moment the name can be customized for the following volume types: - launch - build

In Gradle specifying cache volume names can be done like this:

bootBuildImage {
    cacheVolumeNames = [
        "build": "example-build-cachevol",
        "launch": "example-launch-cachevol"
    ]
}

This PR should resolve #25994.

Comment From: pivotal-cla

@jeliebig Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

Comment From: pivotal-cla

@jeliebig Thank you for signing the Contributor License Agreement!

Comment From: scottfrederick

@jeliebig Thank you very much for your contribution. Your commits have been merged with some changes that you can see in this commit.

After reviewing the Cloud Native Buildpacks changes that this issue was meant to match, we decided that we needed an approach that provided a DSL for configuring the caches instead of a simpler map structure. We also have a desire to support other cache options in the future to align with the CNB direction documented in an RFC. I've added #28386 and #28387 to track these future cache options in Spring Boot.

Comment From: TSRBerry

Thank you for doing this!

For future PRs I would like to ask a few questions if you don't mind. It seems like you had to do a lot of work to merge my PR which I feel like is not optimal. Do you have any feedback for me like things that I could work on, so you don't have to spend so much time on my PRs in the future? Is there any way for me to discuss the approach with you guys beforehand? I would like to avoid that you guys need to do more work just to merge a feature I would like to have, because I couldn't provide a good implementation of it.

Before I created this PR I have done a lot of local testing for a multiö-project build, because my goal is to get caching working for CI builders. During my tests I also implemented cache-images, but trying them out showed no difference to a regular build. The only way I was able to get caching working was to have a previous image of my project which would then provide the metadata and layers for the used buildpacks. Am I doing something wrong or are cache-volumes and cache-images really not used in any way? Even without my changes I wasn't able to see a difference for a regular build and a build with cache-volumes.

I would like to learn more about that and already read a lot of cnb documentation about the lifecycle to get a good understanding about how caching is supposed to work. But since buildpacks can choose if and how layers should be cached, no improvements can be made if a reusable layer does not get cached in the first place. I especially noticed that paketo-buildpacks/bellsoft-liberica would never cache JRE layers even tho they could be used for other builds as long as the java version does not change. If you want to reuse these JRE layers you need to have a previous image from a previous build that they can be exported from. This is just an example, since I saw that most of my build time is distributed to downloading JRE for every CI build. Which leads me to my question, are there any optimizations that I could do to improve this situation? Does spring-boot want these kind of improvements to be made?

Thank you for your time. I hope my questions don't bother you too much.

Comment From: scottfrederick

It seems like you had to do a lot of work to merge my PR which I feel like is not optimal. Do you have any feedback for me like things that I could work on, so you don't have to spend so much time on my PRs in the future?

This was not a case of you doing anything wrong. The original issue #25994 was written to track work that was done in the pack CLI so we can try to maintain parity across CNB tooling, but the issue did not have enough detail and design documented in it. We will often tag issues like that with pending-design to indicate that more work needs to be done, but we did not do that in this case. After looking at your contribution and the CNB RFC that discusses caching changes, it was apparent that we should design this feature with future work in mind. I was keen to get this change into the upcoming 2.6.0-RC1 release so I made the changes without further discussion. Given more time, we could have discussed the design and implementation in the PR.

Even though further work was done, your contribution was very thorough and complete. Thanks again for that.

Is there any way for me to discuss the approach with [the team] beforehand?

You are welcome to add comments to an issue to get clarity on a proposed feature or to say that you'd like to work on a PR for the issue. Sometimes that will prompt us to look closer to see if there is additional design that should be taken into account, and discuss the implementation.

Which leads me to my question, are there any optimizations that I could do to improve [the caching] situation?

I think everything else you've mentioned here is under the control of the CNB builder and buildpacks. Spring Boot can configure caches for the lifecycle but only buildpacks can decide what to cache. If you're using the Paketo builder, you can raise issues in the appropriate Paketo GitHub project or start a discussion with that community. Caching of JRE/JDK specifically has been discussed with the Paketo team in the past.

Comment From: TSRBerry

Thank you so much for answering my questions!

I hope I can create a new PR for this project soon!

Comment From: jdupont22

Hi @TSRBerry, @scottfrederick

Thanks for the try (2021 i know), but buildpack and pack cli now support this kind of use case. Please see pack --cache