[Task] Explore QEMU-free multi-platform image builds

[imbajin]

Problem

The Java build is already native on x86, but every ARM runtime image still runs apt/dpkg through QEMU. We observed one transient QEMU SIGSEGV; PR #23 now mitigates it with per-module retries.

flowchart TB
  subgraph current["Current application publish"]
    C1["x86 runner"] --> C2["Maven build<br/>native x86"]
    C2 --> C3["amd64 runtime image"]
    C2 --> C4["arm64 runtime image"]
    C4 --> C5["apt / dpkg via QEMU"]
    C5 -. "possible SIGSEGV" .-> C6["retry or fail"]
  end

  subgraph candidate["Possible follow-up"]
    P1["Occasional native amd64 + ARM jobs"] --> P2["Shared multi-arch<br/>HugeGraph runtime base"]
    P3["x86 Maven build once"] --> P4["Portable Java package"]
    P2 --> P5["Final images: COPY only"]
    P4 --> P5
    P5 --> P6["amd64 + arm64<br/>without QEMU"]
  end

Loading

Before → After

	Current	Candidate
Java build	x86 native, once	unchanged
ARM runtime setup	apt/dpkg under QEMU	prebuilt on native ARM
Application final stage	contains target-architecture RUN	metadata + COPY only
Failure handling	BuildKit retry	no QEMU in regular publish
Extra maintenance	none	version and refresh a shared runtime base

Suggested PoC

Start with PD only:

1. Build a shared amd64/arm64 JRE runtime base on native runners.
2. Move portable config edits into the x86 build stage.
3. Replace runtime chmod with COPY --chmod.
4. Build and test the PD image without setting up QEMU.
5. Compare wall time, runner time, image size, and reliability.

If the PoC shows a meaningful benefit, extend it to Store, HStore Server, and standalone Server. Upstream Dockerfile changes can be handled separately at that point.

Decision gate

Adopt only if the PoC demonstrates enough benefit to justify maintaining another base image, including its versioning and security-update policy.

Priority: low. The current retry-based workflow is acceptable and this does not block PR #23.

Related: #23