Remote Quarkus build fails on s390x/ppc64le clusters

[lkingland]

Remote builds (func deploy --remote) for Quarkus functions fail on
s390x and ppc64le clusters. The build task gets stuck during the Maven
build phase.

Suspected cause: FSGroup permissions not being honored on the build
PersistentVolume on some s390x/ppc64le clusters, preventing the
build process from accessing its workspace correctly.

Related: SRVOCF-714

[Itx-Psycho0]

/assign

[dikshant182004]

Hi, @lkingland I'd like to work on this issue — could you assign it to me?

I went through the issue history, the previous PR, and the pkg/buildpacks/ source and here's my understanding of why it got reopened:

The previous fix was a partial workaround but the root cause was never addressed — the default builder image for Quarkus in DefaultBuilderImages is still hardcoded to gcr.io/paketo-buildpacks/builder:base, which only ships an amd64 manifest. When this runs on an s390x or ppc64le cluster, the OS tries to execute an amd64 binary on an IBM chip and immediately throws exec format error. Since no test was added to guard the image selection logic for non-amd64 platforms, the regression came back silently.

My proposed fix has three parts:

1. Swap the Quarkus default builder to paketobuildpacks/builder-ubi8-base which ships proper manifests for amd64, s390x, ppc64le, and arm64 — published and maintained by Red Hat specifically for multi-arch workloads:

// pkg/buildpacks/
DefaultBuilderImages = map[string]string{
    // ...
    "quarkus": "paketobuildpacks/builder-ubi8-base", // replaces amd64-only gcr.io image
}

2. Add an architecture mismatch warning inside BuilderImage() — so if a user has manually set an amd64-only builder in their func.yaml and tries to build on an s390x/ppc64le cluster, instead of a cryptic exec format error they get a clear actionable message pointing them to the correct image.

3. Add a unit test for the builder image selection logic on non-amd64 platforms so this cannot regress silently again.

If this approach looks correct to you, I'll move forward and open a PR with the fix, the warning, and the test. Happy to adjust any part of it based on your feedback before I start.

[dikshant182004]

@lkingland Is paketobuildpacks/builder-ubi8-base the right replacement image or we should prefer something from quay.io/boson/?

[lkingland]

Thanks @dikshant182004 — solid root-cause analysis