perf(docker): avoid emulated Java builds

[imbajin]

Summary

• build Hubble and Loader Java/frontend artifacts once on the native BuildKit platform
• keep amd64/arm64 runtime stages target-platform specific
• collapse Loader duplicate Maven packaging into one reactor build
• improve Docker layer ordering and reduce the build context
• document BUILDPLATFORM/TARGETPLATFORM and native dependency boundaries

Measured validation

• Hubble multi-platform build: 147.5 minutes before, 8.8 minutes after
• Loader multi-platform run: roughly 30-40 minutes before, 2.9 minutes after

Read-only validation runs:

• https://github.com/hugegraph/actions/actions/runs/29187794349
• https://github.com/hugegraph/actions/actions/runs/29188191489

Companion workflow/cache changes: hugegraph/actions#22.

Verification

• equivalent JDK 11 Hubble and Loader builds passed
• Loader distribution file set matched the previous build and Loader --help ran on arm64
• native JAR contents were audited for arm64 variants and optional legacy risks documented
• git diff --check passed
• independent cross-repository review passed

[Copilot]

Pull request overview

This pull request optimizes the HugeGraph Hubble Docker image build so that architecture-independent build artifacts are produced once on the native BuildKit build platform and then reused, reducing time spent building under QEMU for multi-platform images.

Changes:

• Force the Docker build stage to run on $BUILDPLATFORM to avoid emulated (QEMU) Maven/Node builds during multi-arch builds.
• Reorder Dockerfile steps so OS package installation can be cached independently of source changes.
• Add a root .dockerignore to shrink the Docker build context while still retaining Maven reactor POMs and required release-doc inputs.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
hugegraph-hubble/Dockerfile	Builds artifacts on the native BuildKit platform and improves layer cache reuse by moving COPY after package install.
.dockerignore	Reduces Docker build context size while preserving needed Maven reactor/module metadata and release-doc inputs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Pengzna]

Reviewed head 563aa1d. I found no new code-level issues. The current check-dependency-license failure is the kotlin-stdlib-common-1.6.20.jar allowlist gap addressed by #741; please rebase or rerun after that lands so the required check is green.

[VGalaxies]

✅ Review summary

Note

The Docker platform pinning, pruned root context, and Loader reactor build are consistent with the Hubble and Loader packaging requirements.

🧪 How this was verified

Independent check	What it traced	Outcome
🏗️ Multi-platform runtime semantics	Followed the BUILDPLATFORM builder stages, target-platform final stages, cross-stage copies, and Java/frontend/native resources in both Dockerfiles.	The reviewer found no target-architecture runtime defect.
📦 Root context and packaging	Traced .dockerignore negations, Docker COPY inputs, Maven reactor modules, Hubble/Loader assembly inputs, and the updated README commands.	The reviewer confirmed that pruning the root context does not remove a required build or packaging input.
🚀 Real amd64/arm64 builds	Inspected the Hubble and Loader validation runs against the PR head and new root build context.	Both multi-platform builds completed successfully; the native-resource audit also confirmed arm64 support in the packaged LZ4, Snappy, Commons Crypto, and shaded gRPC artifacts.

Note

check-dependency-license is currently failing on an unchanged dependency inventory; the review found no link between that failure and this Docker-only diff.

---

_{🤖 Codex review · GPT-5.6 Sol · effort: max}