imbajin commented on issue #2977:
URL: https://github.com/apache/hugegraph/issues/2977#issuecomment-4106238570
Thanks for reviewing this starter task. To provide a full roadmap, here is
the suggested follow-up plan after Phase A.
```text
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.
---
If maintainers agree, I can open separate tracking issues for Phase B and
Phase C with concrete task breakdowns.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
