refactor(vermeer): cross-compile Docker binaries

[imbajin]

Summary

• run the Vermeer Go builder on the native BuildKit platform
• cross-compile the final CGO-disabled binary with TARGETOS and TARGETARCH
• cache Go modules and compiler artifacts
• separate Go and UI dependency downloads from source copies

Measured validation

• previous multi-platform build: 13 minutes 20 seconds
• optimized read-only build: 1 minute 54 seconds
• validation run: https://github.com/hugegraph/actions/actions/runs/29188192310

Companion cache and branch-validation workflow: hugegraph/actions#22.

Verification

• the real amd64/arm64 BuildKit validation completed successfully
• confirmed CGO_ENABLED=0 and explicit TARGETOS/TARGETARCH cross-compilation
• verified Docker COPY paths against the vermeer context and .dockerignore
• git diff --check passed
• independent cross-repository review passed

[Copilot]

Pull request overview

This PR updates Vermeer’s Docker build to avoid QEMU-based cross-builds by running the Go builder stage on the native BuildKit platform and cross-compiling a CGO-disabled target binary using TARGETOS/TARGETARCH. It also improves build performance by adding BuildKit cache mounts and restructuring COPY steps to maximize layer cache hits.

Changes:

• Run the builder stage on $BUILDPLATFORM and cross-compile the final binary with GOOS=$TARGETOS and GOARCH=$TARGETARCH (with CGO_ENABLED=0).
• Add BuildKit cache mounts for Go module downloads and Go compiler build cache.
• Reorder COPY steps to separate dependency downloads (Go modules + UI assets) from the full source copy for better caching.

---

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

[VGalaxies]

✅ Review summary

Note

Cross-compilation is correct, but target-specific arguments currently prevent BuildKit from sharing otherwise target-neutral setup layers.

🧪 How this was verified

Independent check	What it traced	Outcome
🏗️ Multi-platform semantics	Followed BUILDPLATFORM, TARGETOS/TARGETARCH, the CGO_ENABLED=0 build, and the target-specific Alpine final stage.	No wrong-architecture binary or runtime-stage defect was found.
📦 Dependency and UI cache path	Traced go.mod/go.sum, download_ui_assets.sh, ui/package.json, go generate, and the reordered COPY layers.	Confirmed that target arguments are in scope before target-neutral downloads and asset generation, so those layers cannot be shared across target platforms.
🧾 Real Buildx execution	Inspected the amd64/arm64 validation run.	Both images built successfully, while BuildKit logs showed the neutral setup repeated as paired steps 14–15, 20–21, 26–27, and 30–31; this is the evidence behind the inline finding.

---

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

[Pengzna]

Reviewed head f5bd393. I independently confirmed the existing unresolved inline finding and am not duplicating it. I found no additional issues beyond that thread.

[VGalaxies]

✅ Review summary

Note

The Dockerfile correctly cross-compiles Vermeer for the supported Buildx amd64 and arm64 targets without an actionable regression.

🧪 Verification matrix

Independent check	What it traced	Outcome
✅ Cross-platform build semantics Clear	BUILDPLATFORM, TARGETOS, TARGETARCH, CGO settings, final Alpine runtime stage	The reviewer confirmed that the builder runs on the build platform while the Go binary is compiled for the requested amd64 or arm64 target and copied into the matching runtime image.
✅ Dependency and UI preparation Clear	go.mod and go.sum caching, download_ui_assets.sh, asset/vfsgen.go, .dockerignore and COPY ordering	The reviewer confirmed that the reordered Docker layers preserve every dependency, generated UI asset, and embedded-resource input required by the final build.
🧹 Downstream build compatibility Dropped	repository Docker workflows, build_docker.sh, documented image build commands, Buildx requirements	The reviewer raised a legacy-builder concern, but the lead review dropped it because repository and release workflows explicitly use Buildx and document no legacy Docker builder contract.
🟡 Multi-platform execution evidence Limited	external run 29188192310, current-head run 29195060984, local Docker and Go availability	The external validation built both GOARCH=amd64 and GOARCH=arm64 at f5bd393, while current-head execution remained limited because the workflow failed before creating jobs and local build tools were unavailable.

Warning

Verification limits

• The current head could not be built locally because the Docker daemon is stopped and the Go toolchain is not installed.
• The current-head Vermeer CI run ended in startup_failure before creating jobs.

---

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