perf(docker): track follow-up image build optimizations

[imbajin]

Background

The shared Buildx Bake graph from #3171 and hugegraph/actions#27 removed four repeated Maven reactor builds. A real latest publication completed successfully with all four images, both linux/amd64 and linux/arm64, the Compose/Gremlin checks, and the standalone Server smoke test.

Production run: https://github.com/hugegraph/actions/actions/runs/33302286614

The candidate build took 614 seconds. The main critical-path work was:

Work	Observed duration
Full Maven reactor build	about 285s
ARM64 runtime package installation under QEMU	about 149–171s
Local multi-platform image export	up to about 53s
Per-image registry cache export	up to about 100s

The shared build-cache export took about 237 seconds but overlapped much of the runtime work, so BuildKit vertex durations must not be added directly.

Follow-up candidates

1. Put stable runtime dependency layers before source-dependent artifacts

The four runtime stages currently copy Maven artifacts before running apt-get. Any source change therefore invalidates package installation as well, which is particularly expensive under ARM64 emulation.

Move stable package installation before COPY --from=build. Where a command also edits a copied configuration file, split the stable package installation from the source-dependent configuration edit.

Keep the existing operational tools, including vim, procps, curl, dumb-init, and iproute2 where applicable. Removing commonly used operational tools is explicitly out of scope.

Expected result: reuse the runtime dependency layer on ordinary source changes and reduce total build time by roughly 1–2 minutes, subject to a real benchmark.

2. Evaluate a module-scoped Maven build

Determine whether the image build can request only the Server, PD, and Store distribution modules plus their reactor dependencies instead of installing all 38 modules.

Do not skip required assembly inputs or silently weaken validation. Compare the produced distributions and image contents before adopting this change.

3. Re-evaluate native ARM builds only if the simpler changes are insufficient

A native ARM runner could remove QEMU runtime work, but it would add runner coordination and manifest assembly complexity. Keep the current single-job Bake flow unless measurements show a clear end-to-end benefit without reintroducing temporary architecture tags or partially published images.

4. Measure cache export separately

Registry cache export is a meaningful part of the build step, but removing it can merely shift time to the final image push or the next build. Compare both the candidate-build duration and the complete publish duration; do not optimize one metric by moving the same work elsewhere.

Acceptance criteria

• Preserve direct Dockerfile builds and the shared docker/bake.hcl flow.
• Preserve the current runtime tools and published image behavior.
• Produce the same four final image tags with both amd64 and arm64 variants.
• Keep the existing local multi-platform inspection, Compose/Gremlin checks, and standalone Server smoke test before publication.
• Benchmark on the same runner class with a real registry cache and publish path.
• Report both the candidate-build duration and the complete job duration before and after.
• Prefer the runtime-layer reorder first; pursue the other candidates only when their measured benefit justifies the added complexity.