perf(docker): share reactor build across images

[imbajin]

Summary

• add docker/bake.hcl so BuildKit can solve the PD, Store, HStore Server, and standalone Server images together
• keep the Maven build stage identical across the four Dockerfiles and run it once on the native build platform
• build amd64 and arm64 runtime images from the shared Java artifacts
• use one complete shared build cache and separate lightweight runtime caches
• preserve direct Dockerfile builds and the serial fallback used by older source revisions

Companion workflow PR: hugegraph/actions#27

Before → after

flowchart LR
  B[Four image builds] --> C[Four Maven reactor builds]
  A[One Bake graph] --> S[One shared Maven build]
  S --> P[PD runtime]
  S --> T[Store runtime]
  S --> H[HStore Server runtime]
  S --> R[Standalone Server runtime]

Loading

The portable Java build runs once on BUILDPLATFORM. Only the runtime stages fan out for amd64 and arm64, so the expensive Maven work stays native instead of running again through QEMU.

Benchmark

Both measurements used cold caches, the same runner class, the same four images, the same functional checks, and a real Docker Hub publish. Queue time is excluded.

Cold publish	Build step	Complete job	Change
Serial image builds	27m06s	29m32s	baseline
Shared Bake graph	11m10s	13m49s	58.8% faster build, 53.2% faster job

Design

Area	Implementation
Shared work	The four Dockerfiles expose the same native Maven stage, which becomes one reusable LLB node
Multi-platform build	BUILDPLATFORM keeps Maven native; runtime stages use the correct target-platform JRE and only the ARM runtime work uses QEMU
Cache layout	The shared build cache uses mode=max; each runtime image writes its own mode=min cache
Local validation	Both platform variants are loaded into Docker's containerd image store under the final tag before publication
Compatibility	Each Dockerfile remains directly buildable, and source revisions without Bake keep the serial workflow path

CI checks that the shared stages remain identical and validates the evaluated Bake targets, platforms, outputs, and cache layout. The published test images contain both linux/amd64 and linux/arm64 variants. Functional Compose, Gremlin, and standalone checks run against the local amd64 variants before any image is pushed.

Repository housekeeping in this PR moves the build and contribution guides under docs/, updates their references, removes the tracked IntelliJ project metadata, and limits HStore test noise without changing production task lifecycle logging.

Only temporary test tags were published. latest was not changed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 37.76%. Comparing base (321ba4d) to head (4dae0c7).

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3171      +/-   ##
============================================
+ Coverage     32.66%   37.76%   +5.09%     
- Complexity     5500     6539    +1039     
============================================
  Files           789      800      +11     
  Lines         67703    68882    +1179     
  Branches       8945     9147     +202     
============================================
+ Hits          22116    26010    +3894     
+ Misses        42983    39821    -3162     
- Partials       2604     3051     +447     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bitflicker64]

Independently re-verified the core claims. The build stage is byte-identical across all four Dockerfiles at c522d73 (no pre-FROM ARGs, single root .dockerignore), SOURCE_REVISION reaches every Bake target and expands in the cache mount id at runtime, and only the build-cache target writes the shared cache. The timing table matches raw job-step timestamps from the linked hugegraph/actions runs: 1754s -> 330s (dry-run) / 501s (first publish) on the same runner class, with the Maven stage fully rebuilt in both candidate runs. Those runs built 89a2586, whose Dockerfiles and docker-bake.hcl are byte-identical to this head; the strengthened CI guard is covered by the Docker Build CI run on the head itself. Ran buildx bake --print locally: the jq assertion fails on platform or output mutations, and the awk stage-diff catches a divergent mvn line. One hardening nit inline; non-blocking.

Two observations, no action needed in this PR:

• The per-module buildcache-* refs are read but no longer refreshed on the Bake path, so runtime-stage layers will slowly go stale and eventually rebuild each run. If that ever shows in timings, runtime targets could export a cache gated on EXPORT_CACHE.
• Local builds share id=hugegraph-maven-local across revisions, and mvn install writes SNAPSHOTs into that shared .m2. A full-reactor build resolves modules from the reactor, so the practical risk is low; worth a doc line at most.

[imbajin]

Blocking: yes. Summary: The default multi-platform Bake graph configures every runtime target to use the single-platform Docker exporter, so it cannot produce the claimed amd64/arm64 images. Evidence: docker buildx bake --print at c522d73 expands the runtime targets with platforms=[linux/amd64,linux/arm64] and output type=docker; the Docker exporter supports single-platform results.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.