Run image is tagged :v1 for every commit to this repo

[imjasonh]

It looks like this repo's CI builds and pushes a new unique run image as :v1, for every commit.

See https://console.cloud.google.com/gcr/images/buildpacks/GLOBAL/gcp/run?gcrImageListsize=30 -- the :v1 tag has previously pointed to every commit-tagged image listed there.

This is a bit surprising, since many commits to the repo don't actually include any changes which should affect the run image AFAICT (e.g., this change produced this image). But every change produces a new run image which is ~immediately tagged as :v1 and built into images built using GCP Buildpacks. :v1 seems to be little different from :latest in this respect.

This leads me to some questions:

• Is there a reason run images aren't built reproducibly?
• Was this behavior an intentional choice?
• Is there any plan to produce more rigorously released/versioned run images (e.g., with semantic versioning like :v1.2.3) in the future, that users could opt into?

[lukasberger]

This is a known issue/working as intended. The Cloud Build config we use to produce these images is here and is run on every commit.

Is there a reason run images aren't built reproducibly?

The images have apt packages that we want updated to their latest versions as often as new versions are available to pick up security patches. I briefly looked into building the images with bazel and with kaniko, but didn't get very far. IIRC, kaniko wasn't straightforward to set up locally and in a way that both provides reproducibility and picks up latest changes as they are available instead of whenever the cache TTL expires and building images with bazel wasn't compatible with blaze. If you have suggestions here, I'd love to hear them.

Was this behavior an intentional choice?

Yes, but mostly because it was the "easy" choice. We don't have to try to figure out if the particular commit affected the stack images or if whether are any updates to apt packages.

Is there any plan to produce more rigorously released/versioned run images (e.g., with semantic versioning like :v1.2.3) in the future, that users could opt into?

Not currently. Buildpack stack images typically have floating tags so users can pull the most up-to-date run image at build time without having to update their builder image, so there would be no simple way for users to pin a particular version (a :v1.2.3 builder would still pull the latest image by design). That being said, it's possible to manually specify a custom run image when running pack build using the --run-image flag and choosing a particular commit sha from the GCR repo you mention.