paketo-buildpacks/builder-jammy-tiny

GCR images are broken

davidkarlsen opened this issue · 3 comments

Expected Behavior

GCR images should work like docker.io ones

Current Behavior

gcr.io/paketo-buildpacks/build-jammy-tiny fails with:

Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:3.0.6:build-image (default-cli) on project ei-bgc: Execution default-cli of goal org.springframework.boot:spring-boot-maven-plugin:3.0.6:build-image failed: No 'io.buildpacks.builder.metadata' label found in image config labels 'io.buildpacks.stack.description,io.buildpacks.stack.distro.name,io.buildpacks.stack.distro.version,io.buildpacks.stack.homepage,io.buildpacks.stack.id,io.buildpacks.stack.maintainer,io.buildpacks.stack.metadata,io.buildpacks.stack.released,org.opencontainers.image.ref.name,org.opencontainers.image.version' -> [Help 1]

while
paketobuildpacks/builder-jammy-tiny
works fine

Possible Solution

Have same metadata on all iamges

Steps to Reproduce

  1. do a spring-boot build of images which uses packeto under the covers

Motivations

Avoid docker hub which have ever changing policies and limits.

@davidkarlsen I think there's some confusion here - paketobuildpacks/builder-jammy-tiny is a builder but gcr.io/paketo-buildpacks/build-jammy-tiny is a stack build image.

The problem isn't that the metadata is missing, it's that you're trying to use a stack build image in place of a builder.

That being said, the underlying request is valid. I don't believe we publish builders to gcr.io. I'm not necessarily averse to it, but it's not something that's currently top of our priority list.

@davidkarlsen I think there's some confusion here - paketobuildpacks/builder-jammy-tiny is a builder but gcr.io/paketo-buildpacks/build-jammy-tiny is a stack build image.

The problem isn't that the metadata is missing, it's that you're trying to use a stack build image in place of a builder.

That being said, the underlying request is valid. I don't believe we publish builders to gcr.io. I'm not necessarily averse to it, but it's not something that's currently top of our priority list.

Aha, I was confused by the similar naming.

I'm going to close this issue as the actual problem seems to be resolved. We'll track the gcr.io request separately.