Skip to content

chore(devcontainer): build with go.mod's Go toolchain (1.27.2) - #1085

Merged
ako merged 1 commit into
mainfrom
chore/devcontainer-go-1.27
Oct 9, 2026
Merged

ako merged 1 commit into
mainfrom
chore/devcontainer-go-1.27

Conversation

@ako

@ako ako commented Oct 9, 2026

Copy link
Copy Markdown
Owner

Summary

The devcontainer was the last place still on Go 1.26. go.mod and every CI workflow moved to toolchain go1.27.2 in #1064 for five standard-library security fixes (GO-2026-6603 … 6608). The devcontainer base image sets GOTOOLCHAIN=local, so local builds ignored that pin and used the image's own Go (1.26.4 in a current container).

Two changes to .devcontainer/Dockerfile, which both the default and the podman configs build from:

  1. Base image go:dev-1.26-bookworm → go:dev-1.27-bookworm.
  2. ENV GOTOOLCHAIN=auto. The tag bump alone isn't enough: dev-1.27-bookworm currently ships 1.27.1, which is still affected by all five advisories (each is fixed only in 1.26.9 / 1.27.2, per vuln.go.dev). MCR publishes no patch-level tags. With auto, go.mod's toolchain line, the same pin CI uses, selects the version. That keeps the devcontainer in step with future bumps too, not just this one.

Verification

Built this Dockerfile and ran go version against the repo's go.mod:

Image GOTOOLCHAIN go version
this Dockerfile auto go1.27.2 (downloaded on first use)
base dev-1.27-bookworm (control) local go1.27.1

The base image sets GOTOOLCHAIN only as an image ENV; it doesn't write it to /etc/environment. So the ENV override is enough.

Trade-off: the first go command in a new container downloads the 1.27.2 toolchain (about 70 MB, cached afterwards). It disappears once the base tag ships 1.27.2.

Existing containers pick this up on Dev Containers: Rebuild Container.

🤖 Generated with Claude Code

The devcontainer was on go:dev-1.26-bookworm while go.mod and CI moved to
toolchain go1.27.2 (#1064) for five stdlib security fixes
(GO-2026-6603..6608, fixed in 1.26.9 / 1.27.2). The image sets
GOTOOLCHAIN=local, so local builds ignored the pin and used the image's
Go: 1.26.4 here.

Bumping the tag alone is not enough: dev-1.27-bookworm ships 1.27.1,
which is still affected, and the image has no patch-level tags. So also
set GOTOOLCHAIN=auto, letting go.mod's toolchain line — the same pin CI
uses — select the version, now and on future bumps.

Verified by building this Dockerfile and running `go version` against the
repo's go.mod:
  this image          GOTOOLCHAIN=auto   go1.27.2 (downloaded)
  base image (control) GOTOOLCHAIN=local go1.27.1

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ako
ako merged commit a541fc1 into main Oct 9, 2026
31 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant