Fix multi-arch Docker build SIGILL by splitting frontend stage

[silverwind]

Summary

• Split Dockerfile and Dockerfile.rootless into a two-stage build: frontend assets are built on the native platform ($BUILDPLATFORM) then copied to the per-architecture backend build stage
• This avoids running esbuild/webpack under QEMU emulation which causes SIGILL (Invalid machine instruction) on arm64/riscv64
• Frontend assets (JS/CSS/fonts) are platform-independent so they only need to be built once
• The build-env stage no longer needs nodejs/pnpm since it only builds the Go backend

Context

The docker-dryrun CI has been failing with 100% rate whenever the container job is triggered because esbuild's native arm64 binary crashes under QEMU user-mode emulation. This is a known class of issues (evanw/esbuild#3153, docker/buildx#2028). The previous Dockerfile had a TODO comment anticipating this fix.

Test plan

• Verify docker-dryrun CI passes (container job)
• Verify the produced images work correctly on amd64, arm64, and riscv64

🤖 Generated with Claude Code

[silverwind]

This fixes the persistent build issue with SIGILL seen in docker-dryrun on riscv64 while speeding up the docker build itself by building frontend assets only once and not on every platform separately.

[silverwind]

Example of the SIGILL failure: https://github.com/go-gitea/gitea/actions/runs/22049014112/job/63703196222

#36 [linux/arm64 build-env 5/7] RUN make
#36 279.3 undefined
#36 279.4  ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL  Command was killed with SIGILL (Invalid machine instruction): webpack --disable-interpret
#36 279.8 make: *** [Makefile:806: public/assets/js/index.js] Error 1

[Copilot]

Pull request overview

This pull request fixes multi-architecture Docker build failures by splitting the build process into two stages: a frontend build stage that runs on the native platform and a backend build stage that runs on each target architecture. This change addresses SIGILL crashes caused by running esbuild under QEMU emulation when building for arm64 and riscv64.

Changes:

• Split Dockerfile into frontend-build and build-env stages, with frontend running on $BUILDPLATFORM
• Removed nodejs/pnpm dependencies from backend build stage since they're no longer needed
• Changed backend stage to run make backend instead of make to avoid attempting frontend rebuild
• Applied identical changes to both Dockerfile and Dockerfile.rootless for consistency

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
Dockerfile	Added frontend-build stage on native platform; backend stage now copies frontend assets and only builds Go binary
Dockerfile.rootless	Identical split-stage changes as Dockerfile, maintaining consistency for rootless builds

---

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

[silverwind]

Assuming dryrun completes, this should be ready.

[silverwind]

FYI, This branch results in a roughly 9% speed up of the docker-dryun workflow because of the frontend build now only executing once.

[TheFox0x7]

I've tested it - image builds properly, there's no size difference and it starts as before so I see no issues.

[wxiaoguang]

Very useful improvement.

ps: I was trying to look for something like INCLUDE ./Dockerfile.common to share the FROM --platform=$BUILDPLATFORM docker.io/library/golang:1.26-alpine3.23 AS frontend-build step , but I failed. It seems that Docker still doesn't have easy support for "build file inclusion" officially.

[silverwind]

Yeah something to eliminate the duplication would be nice.

[TheFox0x7]

Podman has support for cpp preprocessing so you could have #include <Dockerfile.common> but... it's less then great. IMO if you want to de-duplicate it somewhat then a single file would be easiest. Otherwise I think docker's bake could do this, though it would make my local builds funny if we swap.