Background
#3665 (merged 2026-05-09) fixed the immediate symptom of #3515 — remote Quarkus builds failing on s390x/ppc64le clusters — but the root cause remained: DefaultBuilderImages["quarkus"] is hardcoded to gcr.io/paketo-buildpacks/builder:base, which only ships an amd64 manifest. Without a regression test, an equivalent issue can recur silently the next time a non-amd64 architecture surfaces.
When a non-amd64 cluster (s390x, ppc64le) selects the current Quarkus default builder, the OS attempts to execute an amd64 binary on a non-amd64 chip and immediately throws exec format error. The DefaultBuilderImages map in pkg/buildpacks/ selects the builder image purely by language, with no platform awareness.
Proposed solution
-
Swap the Quarkus default builder to a multi-arch image (amd64, s390x, ppc64le, arm64).
DefaultBuilderImages = map[string]string{
// ...
"quarkus": "paketobuildpacks/builder-ubi8-base", // candidate — multi-arch UBI
}
Open question: paketobuildpacks/builder-ubi8-base vs an internal quay.io/boson/... image. I'll surface this with the team and follow up before implementation starts.
-
Architecture-mismatch warning in BuilderImage() — if a user has manually pinned an amd64-only builder in their func.yaml and tries to build on s390x/ppc64le, emit a clear actionable error instead of the raw exec format error.
-
Regression test for builder-image selection on non-amd64 platforms so this can't recur silently.
Verification
Should be verified end-to-end on an actual s390x or ppc64le cluster. Hardware-access question is open with @Itx-Psycho0 / @dikshant182004; if neither has access I'll arrange something on our side.
Related
Background
#3665 (merged 2026-05-09) fixed the immediate symptom of #3515 — remote Quarkus builds failing on s390x/ppc64le clusters — but the root cause remained:
DefaultBuilderImages["quarkus"]is hardcoded togcr.io/paketo-buildpacks/builder:base, which only ships anamd64manifest. Without a regression test, an equivalent issue can recur silently the next time a non-amd64 architecture surfaces.Analysis (credit @dikshant182004)
When a non-amd64 cluster (s390x, ppc64le) selects the current Quarkus default builder, the OS attempts to execute an amd64 binary on a non-amd64 chip and immediately throws
exec format error. TheDefaultBuilderImagesmap inpkg/buildpacks/selects the builder image purely by language, with no platform awareness.Proposed solution
Swap the Quarkus default builder to a multi-arch image (
amd64,s390x,ppc64le,arm64).Open question:
paketobuildpacks/builder-ubi8-basevs an internalquay.io/boson/...image. I'll surface this with the team and follow up before implementation starts.Architecture-mismatch warning in
BuilderImage()— if a user has manually pinned an amd64-only builder in theirfunc.yamland tries to build on s390x/ppc64le, emit a clear actionable error instead of the rawexec format error.Regression test for builder-image selection on non-amd64 platforms so this can't recur silently.
Verification
Should be verified end-to-end on an actual s390x or ppc64le cluster. Hardware-access question is open with @Itx-Psycho0 / @dikshant182004; if neither has access I'll arrange something on our side.
Related