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
- 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 butgcr.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.