[Task] Improve Docker build cache efficiency for pd/store/server images

[imbajin]

Background

The Docker images for hugegraph-pd, hugegraph-store, and hugegraph-server currently build with this pattern:

1. COPY . /pkg
2. RUN mvn package ...
3. Copy build outputs into runtime image

This causes low cache efficiency:

• Any repository file change (even non-Java files) can invalidate the COPY layer.
• The expensive mvn package step is re-run too often.
• CI time stays high even when Java code is unchanged.

Goal

Improve Docker build cache hit rate and reduce unnecessary Maven rebuild time, without changing image runtime behavior.

Scope (Starter Task / Phase A)

Please focus on the low-risk, high-impact subset:

• Improve .dockerignore to exclude files that should not affect image build cache (for example: .git/, IDE files, temp files).
• Refactor Dockerfile layer order so dependency-related files are copied before source files where practical.
• Use BuildKit Maven cache mount (--mount=type=cache,target=/root/.m2) in Maven build steps.
• Keep existing image entrypoints/ports/runtime behavior unchanged.

Out of Scope (Do NOT include in this issue)

• Full artifact pipeline split ("build once, package many images").
• Cross-repo CI architecture redesign.
• New release logic or tag strategy changes.

Deliverables

• A PR with Dockerfile and/or .dockerignore updates.
• A short before/after note from CI showing cache behavior and build time delta.

Acceptance Criteria

• A second build with no Java source changes shows clear improvement in build time and/or cache hits.
• Existing image smoke/integration checks still pass.
• No functional regression in generated images.

Suggested Starting Points

• hugegraph-pd/Dockerfile
• hugegraph-store/Dockerfile
• hugegraph-server/Dockerfile
• hugegraph-server/Dockerfile-hstore

If the scope starts growing, keep this issue focused on Phase A and open follow-up issues for larger refactors.

[imbajin]

To provide a full roadmap, here is the suggested follow-up plan after Phase A.

Roadmap overview
Phase A (this issue) -> Phase B (build once/package many) -> Phase C (long-term maintainability)

Phase B (Core Efficiency): Build Once, Package Many

Objective

Remove repeated Maven builds across pd/store/server image pipelines by producing reusable build artifacts once per commit.

Suggested Scope

• Add a CI step/job that runs Maven once and produces standardized artifacts for:
  • pd
  • store
  • server-hstore
  • server-standalone
• Publish these artifacts via CI artifact storage.
• Refactor image builds to consume artifacts instead of running mvn package inside each image Dockerfile.
• Keep runtime image behavior unchanged (entrypoint, ports, env defaults).

Acceptance Criteria

• Maven build is executed once per commit in the image publish flow.
• pd/store/server images are packaged from the produced artifacts.
• Functional parity with current images is verified by smoke/integration checks.
• End-to-end CI time for the full image set shows a significant reduction.

Recommendation

Track Phase B in one dedicated issue/PR series, because it changes build architecture and cross-job artifact flow.

Phase C (Maintainability): Configuration and Script Convergence

Objective

Reduce long-term maintenance overhead and avoid drift between server variants.

Suggested Scope

• Consolidate duplicated startup/config templating logic where possible.
• Clearly model variant-specific behavior (standalone vs hstore) through parameters/templates.
• Add lightweight build observability:
  • module-level build duration
  • cache hit/miss indicators
  • architecture-level trend tracking (amd64 / arm64)

Acceptance Criteria

• Shared logic is centralized and variant differences remain explicit.
• No runtime behavior regression for either server mode.
• Build metrics are visible enough to validate future optimization impact.

Recommendation

Treat Phase C as incremental improvements across multiple small PRs after Phase B is stable.

---

Could use sub-issue / task for each step

[zeel2104]

I would like to work on it. Could you assign it to me?