ci: build multi-arch images with native Go builder#420
Conversation
Signed-off-by: ranxi2001 <ranxi169@163.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the builder stages in docker/Dockerfile, docker/Dockerfile.picod, and docker/Dockerfile.router to use --platform=$BUILDPLATFORM for multi-architecture support. The feedback recommends optimizing the Docker build cache by moving the platform-specific build arguments (ARG TARGETOS and ARG TARGETARCH) to after the go mod download step, which prevents dependency download cache invalidation during multi-platform builds.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| @@ -1,5 +1,5 @@ | |||
| # Multi-stage build for workloadmanager | |||
| FROM golang:1.26.4-alpine AS builder | |||
| FROM --platform=$BUILDPLATFORM golang:1.26.4-alpine AS builder | |||
There was a problem hiding this comment.
To fully optimize the multi-architecture build cache, declare the platform-specific build arguments ARG TARGETOS and ARG TARGETARCH after the go mod download step (just before the go build step).
Currently, because they are declared at the top of the Dockerfile (lines 5-6), any change in the target platform (e.g., building for amd64 and arm64 simultaneously) will invalidate the cache for all subsequent steps, including go mod download. This forces Go to download dependencies twice (once for each architecture).
Moving these ARG declarations to just before the go build step allows the go mod download layer to be cached and shared across all target platforms.
| @@ -1,5 +1,5 @@ | |||
| # Build stage | |||
| FROM golang:1.26.4 AS builder | |||
| FROM --platform=$BUILDPLATFORM golang:1.26.4 AS builder | |||
There was a problem hiding this comment.
To fully optimize the multi-architecture build cache, declare the platform-specific build arguments ARG TARGETOS and ARG TARGETARCH after the go mod download step (just before the go build step).
Currently, because they are declared at the top of the Dockerfile (lines 5-6), any change in the target platform (e.g., building for amd64 and arm64 simultaneously) will invalidate the cache for all subsequent steps, including go mod download. This forces Go to download dependencies twice (once for each architecture).
Moving these ARG declarations to just before the go build step allows the go mod download layer to be cached and shared across all target platforms.
| @@ -1,5 +1,5 @@ | |||
| # Multi-stage build for agentcube-router | |||
| FROM golang:1.26.4-alpine AS builder | |||
| FROM --platform=$BUILDPLATFORM golang:1.26.4-alpine AS builder | |||
There was a problem hiding this comment.
To fully optimize the multi-architecture build cache, declare the platform-specific build arguments ARG TARGETOS and ARG TARGETARCH after the go mod download step (just before the go build step).
Currently, because they are declared at the top of the Dockerfile (lines 5-6), any change in the target platform (e.g., building for amd64 and arm64 simultaneously) will invalidate the cache for all subsequent steps, including go mod download. This forces Go to download dependencies twice (once for each architecture).
Moving these ARG declarations to just before the go build step allows the go mod download layer to be cached and shared across all target platforms.
There was a problem hiding this comment.
Pull request overview
This PR optimizes multi-arch image builds by running the Go builder stage on $BUILDPLATFORM (native to the runner) while still compiling binaries for TARGETOS/TARGETARCH, avoiding QEMU-emulated Go compilation during linux/arm64 builds.
Changes:
- Set the builder stage in all three image Dockerfiles to
FROM --platform=$BUILDPLATFORM ... AS builder.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
docker/Dockerfile |
Switches workloadmanager builder stage to run on $BUILDPLATFORM. |
docker/Dockerfile.router |
Switches router builder stage to run on $BUILDPLATFORM. |
docker/Dockerfile.picod |
Switches PicoD builder stage to run on $BUILDPLATFORM. |
| # Multi-stage build for workloadmanager | ||
| FROM golang:1.26.4-alpine AS builder | ||
| FROM --platform=$BUILDPLATFORM golang:1.26.4-alpine AS builder |
| # Multi-stage build for agentcube-router | ||
| FROM golang:1.26.4-alpine AS builder | ||
| FROM --platform=$BUILDPLATFORM golang:1.26.4-alpine AS builder |
| # Build stage | ||
| FROM golang:1.26.4 AS builder | ||
| FROM --platform=$BUILDPLATFORM golang:1.26.4 AS builder |
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #420 +/- ##
===========================================
+ Coverage 47.57% 58.50% +10.93%
===========================================
Files 30 36 +6
Lines 2819 3463 +644
===========================================
+ Hits 1341 2026 +685
+ Misses 1338 1228 -110
- Partials 140 209 +69
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
What type of PR is this?
/kind enhancement
What this PR does / why we need it:
This PR optimizes the multi-arch image build path by running the Go builder stages on
$BUILDPLATFORMwhile keepingTARGETOS/TARGETARCHfor cross-compilation.On x64 GitHub-hosted runners, the previous Dockerfiles ran the
linux/arm64Go builder stage under QEMU. In the release-image benchmark recorded in #419, the workloadmanagerlinux/arm64Go build was the dominant cost. This change keeps the produced images multi-arch, but avoids running the Go compiler through arm64 emulation.Scope of this first PR:
docker/Dockerfile,docker/Dockerfile.router, anddocker/Dockerfile.picod.This PR does not conflict with #416 because #416 changes the release workflow metadata and Helm chart version handling, while this PR only changes Dockerfile builder stages. It is also separate from #264, which adjusts workloadmanager build entrypoints and Makefile flow.
Which issue(s) this PR fixes:
Refs #419
Special notes for your reviewer:
docker/Dockerfile,docker/Dockerfile.router,docker/Dockerfile.picod.git diff --check upstream/main...HEADmake build-alldocker buildx build --builder agentcube-day39 --platform linux/amd64,linux/arm64 -f docker/Dockerfile --target builder --progress=plain .docker buildx build --builder agentcube-day39 --platform linux/amd64,linux/arm64 -f docker/Dockerfile.router --target builder --progress=plain .docker buildx build --builder agentcube-day39 --platform linux/amd64,linux/arm64 -f docker/Dockerfile.picod --target builder --progress=plain .ranxi2001:ci/native-build-platform-images: 9/9 workflows passed.Does this PR introduce a user-facing change?: