Go companion image still on Go 1.26 after v0.3.8 Go 1.27 bump (breaks container builds of go 1.27.0 services)

[antoinetoussaint-byte]

Summary

The Go companion image (codeflydev/go, built from companions/go/Dockerfile) is still FROM golang:1.26-alpine and pinned at info.codefly.yaml version 0.0.10, which ships Go 1.26.4. Meanwhile core v0.3.8 moved the ecosystem to Go 1.27 (services now emit go 1.27.0 in their go.mod).

Because the agent uses this companion to go build the service in container / Docker-run mode, a service on go 1.27.0 cannot build under the 1.26.4 toolchain:

go: downloading go1.27.0 (linux/amd64)
go: download go1.27.0 for linux/amd64: toolchain not available

The build fails, the server never starts, and the health check gets connection reset by peer.

Where it bit

codefly-dev/service-go-grpc PR #85 (bump core to v0.3.8, Go 1.27). TestCreateToRunDocker failed — the container (codeflydev/go:0.0.10) could not build the generated go 1.27.0 module. Native tests passed (host Go is 1.27). Confirmed by reproducing the build inside codeflydev/go:0.0.10 locally.

Interim fix (already shipped in service-go-grpc)

Published codeflydev/go:0.0.11 built FROM golang:1.27-alpine (Go 1.27.0) and pinned runtimeImage + GoVersion to 1.27 in that repo. This unblocks CI but diverges from what core's companions/go declares.

Ask (durable fix in core)

• Bump companions/go/Dockerfile to FROM golang:1.27-alpine.
• Set companions/go/info.codefly.yaml version: 0.0.11 so golang.CompanionImage() resolves to the Go 1.27 image already published.
• Republish via codefly companion publish (the 0.0.11 tag matching the image service-go-grpc now depends on).
• Audit the other language companions and GoVersion/builder-base pins for the same 1.26→1.27 drift so "Go 1.27 everywhere" is consistent across the ecosystem.

Ref: companions/go/version.go derives the tag from info.codefly.yaml; the service repo hardcodes runtimeImage = codeflydev/go:<tag> independently.