Why paketobuildpacks/run image download everytime

base: Pulling from paketobuildpacks/builder
Digest: sha256:0ea77b1be8d415639a36cc476c515bb492bf2a35274da4686caddbd897059b44
Status: Image is up to date for paketobuildpacks/builder:base
base-cnb: Pulling from paketobuildpacks/run
Digest: sha256:3bdefd40188e93e4aba93978440816f9b86d03a1a7b58e6c6c854bcb88df8ace
Status: Image is up to date for paketobuildpacks/run:base-cnb

This isn't actually downloading. It's checking if it has the latest, which is the default behavior. You can control this with the --pull-policy flag to pack build. It defaults to always, but can also be set to never and if-not-present.

I prefer if-not-present if I'm doing a lot of builds in a row because I already know I have the most recent image and that will skip the check for the latest version which is marginally faster.

I don't use --never, while it'll achieve the same result, I find it's a little annoying because if I change up the buildpacks I'm using and add a new one I do not have downloaded locally then the build fails until I can remember to switch the flag or pull down the missing image.

In either case, you need to remember that you're setting this flag and not use it when you're building production images where you always want to make sure that you have the latest base images.

And it download gradle everytime too.

This shouldn't usually happen. It's hard to say what is causing this based on the information provided, but here's a breakdown of what should happen.

1. When you build your app, the gradle buildpack is going to execute the gradle wrapper (because you have a Spring Boot app and it uses the wrapper by default). That's the output you're seeing. The wrapper running, and the wrapper should typically only install gradle once per version.

2. When you pack build for the first time, the gradle buildpack will execute the gradle wrapper, which downloads and install gradle. This should result in the gradle bits being stored on a layer that's cached for future runs.

3. After gradle is installed, the gradle buildpack will build your application and produce an executable JAR (cause it's a Spring Boot app). That's the end of the gradle buildpack.

4. It's not the end of the build though. The executable JAR and Spring Boot buildpacks then run and perform their tasks.

5. When all of the buildpacks complete successfully, the lifecycle will export all of the layers (including cached layers). At this point, you should have an image that you can run.

6. If you go to pack build again, using the same image name, pack will do some analysis and locate the images and cached layers from your previous run. It'll restore those and when the gradle buildpack runs the gradle wrapper, the wrapper will see the files from the previous build and should not download anything new.

Potential reasons why it might re-download unexpectedly:

1. The first build does not complete. As mentioned, the cached layers are not saved until the full pack build completes. If any part of the initial build fails, the cached layers are not saved, and running a subsequent build will re-download gradle. This is a known limitation with buildpacks and is being worked on at the time I write this post.

2. Changing the image name. If you do a subsequent pack build with a different image name, that is basically like doing a new build. The cache image layers are scoped to the image, which is determined by the image name you set. Changing the name, like if you have a commit hash or the date in your image name, will result in poor caching performance.

3. The version of Gradle has changed, so the wrapper legitimately needs to install a new version of Gradle (it doesn't sound like this is the case).

4. Possibly other things. If you update your post with the full output from running your initial pack build as well as the subsequent pack build where it does not cache the download, that would help to determine more about what is happening.