Release linux/arm64 for all service agents (multi-arch support)

[antoinetoussaint-byte]

Summary

The six language service agents ship only darwin/amd64, darwin/arm64, and linux/amd64 — none has a linux/arm64 build. Multi-arch is a confirmed requirement, so this blocks running Codefly services on any arm64 Linux target (arm64 companion images, arm64 CI runners, arm64 K8s nodes).

All pinned versions ARE released; the gap is purely the missing linux/arm64 platform, and it is identical across every service-* repo — a release-matrix omission, not a per-repo miss.

Why it matters / blast radius

• Nothing currently published is broken: registry companions are pinned linux/amd64 (cli companions.yaml), Apple Silicon devs run codefly natively as darwin/arm64, CI is amd64.
• It breaks the moment anything runs services on arm64 Linux. The companion CLI builds/runs services in-container and resolves the matching service-<name> agent for the container arch; on arm64 there is no service-*_linux_arm64.tar.gz, so agent resolution fails at runtime.
• Live footgun today: codefly companion build/publish on an Apple Silicon Mac defaults to arm64 (dockerArch() → arm64), producing an arm64 companion that cannot run a single language service. CI only avoids it by explicitly passing --platform linux/amd64.

Why it's not a one-line matrix add

The agents require cgo — each links its own tree-sitter grammar (CGO_ENABLED=1 in their goreleaser). A linux/arm64 build therefore needs the aarch64 cross-cgo toolchain (CC=aarch64-linux-gnu-gcc, CXX=aarch64-linux-gnu-g++).

Good news — the toolchain is already present. Each service-* release runs under ghcr.io/goreleaser/goreleaser-cross:v1.26.4 (same image the CLI's own release uses to build all four platforms), which already ships aarch64-linux-gnu-gcc. So the fix is a goreleaser-only change; no release-workflow change is needed.

(This is a concrete real-world cost of the cgo surface tracked in #345: if agents were CGO-free, linux/arm64 would be a trivial goarch addition. Cross-linking for that reason.)

Reference change (service-go — copy to each repo, adjusting binary:)

Add after the linux-amd64 build stanza in .goreleaser.yaml, before archives::

 - id: linux-arm64
 binary: service-go # service-python / service-rust / ... per repo
 env:
 - CGO_ENABLED=1
 - CC=aarch64-linux-gnu-gcc
 - CXX=aarch64-linux-gnu-g++
 goos:
 - linux
 goarch:
 - arm64

The archives name_template already emits service-{name}_{version}_{os}_{arch}.tar.gz, so the new asset (..._linux_arm64.tar.gz) matches core's downloader contract automatically — no archive change.

Checklist (add linux/arm64, cut a new release)

• codefly-dev/service-go (currently v0.0.33)
• codefly-dev/service-python (v0.0.52)
• codefly-dev/service-nextjs (v0.0.141)
• codefly-dev/service-rust (v0.0.29)
• codefly-dev/service-swift (v0.0.16)
• codefly-dev/service-generic (v0.0.26)
• Bump the pins in cli pkg/sourceworkspace/source.go if the versions roll
• Once agents publish arm64, allow multi-arch companions (drop / broaden the --platform linux/amd64 pin in cli companions.yaml) and consider a CI check that a linux/arm64 companion can resolve every language agent

Verification per repo

After the release, confirm the asset exists, e.g.:

gh release view v<version> --repo codefly-dev/service-<name> --json assets \
 --jq '[.assets[].name | select(contains("linux_arm64"))]'

Related

• [refactor] Investigate core's CGO dependency surface and where the CGO-free switch should live #345 — [refactor] investigate core's CGO dependency surface (agents' cgo requirement is what makes this non-trivial)
• fix: build a CGO-free CLI so companion publish links statically cli#456 — CGO-free CLI (surfaced this while publishing the Go 1.27 companion)

[antoinetoussaint-byte]

Investigated core's side of this. Core needs no code change for linux/arm64 — its agent downloader and every store (OCI/HTTP/Nix) already resolve assets via runtime.GOOS/runtime.GOARCH, and the CLI self-updater already handles EM_AARCH64/CpuArm64. On an arm64 Linux host, core already requests service-<name>_<version>_linux_arm64.tar.gz; the asset simply 404s today because the publishers don't emit it yet.

So this is purely the cross-repo release work the checklist already names, none of it in codefly-dev/core:

• Add the linux-arm64 goreleaser build + cut a release in each service-* repo (service-go, service-python, service-nextjs, service-rust, service-swift, service-generic).
• Bump the pins in cli pkg/sourceworkspace/source.go and broaden the --platform linux/amd64 companion pin in cli companions.yaml.

I opened #348 as a core-side artifact but reverted it to empty and am closing it: the only test I could add there was tautological (the download path has no arch-dependent branching — it's a plain fmt.Sprintf), so it caught nothing the existing host-platform test doesn't. Keeping this issue open since the real releases above are still pending.