Skip to content

Install the toolchain with mise, like everything else - #6

Merged
nicodes merged 2 commits into
mainfrom
chore/mise-toolchain
Aug 3, 2026
Merged

Install the toolchain with mise, like everything else#6
nicodes merged 2 commits into
mainfrom
chore/mise-toolchain

Conversation

@nicodes

@nicodes nicodes commented Aug 3, 2026

Copy link
Copy Markdown
Owner

Completes the fleet-wide toolchain standardization. Every repo now installs through mise-action.

What this gives up, and how it is covered

I argued against this change when it was proposed, and the argument is worth recording because the code already made it:

Read from go.mod rather than pinned here, so the version lives in one place and a bump cannot leave CI testing the old one.

That is correct. setup-go with go-version-file: go.mod genuinely kept the Go version in exactly one place, and a new .mise.toml creates a second. This repo had no .mise.toml at all — it is pure Go, with no bun or PocketBase pins needing a home.

So rather than accept the drift, it is checked. A Toolchain pins agree step reads both files and fails the run if .mise.toml pins an older Go than go.mod asks for.

That failure is not hypothetical. astry's own config records hitting it:

It was 1.24.5, which built only because GOTOOLCHAIN=auto quietly downloaded 1.25 behind the pin — so the pin described nothing.

Tested both directions: it passes on the current pins and rejects 1.25 against a go.mod asking for 1.26.

The other half

setup-go was caching the Go build for free (cache: true is the v4+ default). mise-action installs the toolchain and caches nothing else, so the cache is now explicit — keyed on go.sum + .mise.toml, written once per dependency change.

Without that step this change would have traded a warm compile for a cold one on every run, which is exactly the fleet-wide problem the rest of this work has been fixing.

Applies to ci.yml and release.yml both.

🤖 Generated with Claude Code

nicodes and others added 2 commits August 2, 2026 23:44
Neither reads the other's output: the build action cross-compiles and asks the
binary for its version, and the test action formats, vets and tests the source.
So the order decides one thing only -- which failure you hear about sooner --
and a vet or test failure is a more common way to break this than the
cross-compile is.

Nothing else changes here. setup-go already keeps a Go build cache and the run
log shows it restoring, which is why this repository needs none of the cache
work the mise-based ones did.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Every repository in the fleet now installs its toolchain through mise. This one
used setup-go, and while that was defensible on its own terms it meant the
answer to "which Go builds this" depended on which repository you were standing
in.

The comment this replaces made the real argument against changing it: reading
go-version-file: go.mod kept the version in one place, and a bump could not
leave CI testing the old one. That argument is sound and the change gives it up,
so it is replaced rather than deleted -- a new .mise.toml is a second place for
the version to live.

What makes that acceptable is that the drift is now checked instead of hoped
for. "Toolchain pins agree" reads both files and fails the run if .mise.toml
pins an older Go than go.mod asks for. That failure is not hypothetical: astry
pinned 1.24.5 against a go.mod asking for 1.25 and built anyway, because
GOTOOLCHAIN=auto fetched the real one behind the pin -- so the pin described
nothing and nothing said so.

setup-go was also caching the Go build for free, which mise does not do. That
cache is now explicit, keyed on go.sum and the toolchain pin, so dropping
setup-go does not quietly trade a warm compile for a cold one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@nicodes
nicodes merged commit 250b6c7 into main Aug 3, 2026
1 check passed
@nicodes
nicodes deleted the chore/mise-toolchain branch August 3, 2026 06:46
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