Operating System
What feature would you like to be added?
Add a CI target that runs the test suite natively on Windows/arm64, not just build-only cross-compilation.
Today .github/workflows/test.yml exercises Windows on windows-latest (amd64) and also includes a 32-bit go test (Windows 386) leg. For arm64 it only cross-compiles a binary:
env GOOS=windows GOARCH=arm64 go build -v ./...
so go test never actually executes on Windows-on-Arm. GitHub Actions now offers hosted windows-11-arm runners (free for public repositories), which makes a real arm64 test leg feasible. This could be a new matrix entry or a dedicated job, mirroring the existing Windows steps (CGO_ENABLED=0/1, -N -l, race).
Open question — not yet decided: how to keep the added wall-clock time reasonable. The current Windows leg runs across all 9 Go versions (1.18–1.26) with -count=10 for both CGO_ENABLED=0 and 1, plus the -N -l and race variants, so naively cloning it for arm64 would roughly add a whole extra Windows column. Some candidate mitigations (to be discussed, none chosen yet):
- Restrict the arm64 leg to only the latest one or two Go versions, following the precedent already used by the
minor-arches and bsd jobs and the "Linux minor architectures" build step.
- Lower
-count for this leg.
- Drop sub-steps that don't apply on arm64 (e.g. the Windows 386 leg) and possibly trim the
-N -l / race variants.
- Run the leg conditionally (e.g. only on the latest Go, on a schedule, or path-filtered) rather than on every push/PR.
Why is this needed?
Windows/arm64 is a supported target whose assembly/calling-convention code paths currently have no native test coverage — they are only smoke-tested via cross-compilation. macOS already tests arm64 natively (macos-latest is Apple Silicon) and Linux has ubuntu-24.04-arm, so Windows is the only OS in the matrix without a native arm64 run. This gap is not hypothetical: #205 was a Windows/arm64-specific go test failure, and struct support for Windows amd64/arm64 was only just added in #465. Native CI would catch arm64-specific regressions that cross-compilation cannot.
Filed by Claude (Claude Code), on behalf of @hajimehoshi.
Operating System
What feature would you like to be added?
Add a CI target that runs the test suite natively on Windows/arm64, not just build-only cross-compilation.
Today
.github/workflows/test.ymlexercises Windows onwindows-latest(amd64) and also includes a 32-bitgo test (Windows 386)leg. For arm64 it only cross-compiles a binary:env GOOS=windows GOARCH=arm64 go build -v ./...so
go testnever actually executes on Windows-on-Arm. GitHub Actions now offers hostedwindows-11-armrunners (free for public repositories), which makes a real arm64 test leg feasible. This could be a new matrix entry or a dedicated job, mirroring the existing Windows steps (CGO_ENABLED=0/1,-N -l, race).Open question — not yet decided: how to keep the added wall-clock time reasonable. The current Windows leg runs across all 9 Go versions (1.18–1.26) with
-count=10for bothCGO_ENABLED=0and1, plus the-N -land race variants, so naively cloning it for arm64 would roughly add a whole extra Windows column. Some candidate mitigations (to be discussed, none chosen yet):minor-archesandbsdjobs and the "Linux minor architectures" build step.-countfor this leg.-N -l/ race variants.Why is this needed?
Windows/arm64 is a supported target whose assembly/calling-convention code paths currently have no native test coverage — they are only smoke-tested via cross-compilation. macOS already tests arm64 natively (
macos-latestis Apple Silicon) and Linux hasubuntu-24.04-arm, so Windows is the only OS in the matrix without a native arm64 run. This gap is not hypothetical: #205 was a Windows/arm64-specificgo testfailure, and struct support for Windows amd64/arm64 was only just added in #465. Native CI would catch arm64-specific regressions that cross-compilation cannot.Filed by Claude (Claude Code), on behalf of @hajimehoshi.