Fix GitHub Actions setup-go Version Errors
Zusammenfassung
Pixel’s announcement explains why GitHub Actions setup-go may fail to find a Go version and how to diagnose the quoted version spec. It covers unrecognized version files, unexpected file contents, and platform or architecture mismatches that prevent a published Go build from being found.
DEV Community
GitHub Actions setup-go unable to find go version, and what is in the quotes
GitHub Actions setup-go unable to find go version is thrown after the action has searched the published Go download index and found nothing that satisfies the spec it was given for this operating system and this architecture. The spec is quoted in the message, and reading what is inside the quotes settles almost every instance of this failure, because the spec is frequently not the string anybody wrote. The basename dispatch and the fall-through are read from parseGoVersionFile in src/installer.ts. The framed line is quoted from ctrl-research/mmo#3, shortened at the ellipses. What this error means A setup-go step fails before anything is installed, with a message naming a version, a platform and an architecture. Look at the quoted spec first and ask whether it is what you expected. Three shapes turn up. A plausible version number means the spec was right and no published build matches it for that platform and architecture. A version you never wrote means it came from a file rather than from the workflow. The contents of an entire file, comments and all, means the action read a file whose name it does not recognise and used the whole thing as a version string. The platform and architecture at the end of the message are not decoration: the search matches a per-file operating system and architecture, so a version that exists can still be unfindable here. ```Actions log, quoted from ctrl-research/mmo#3; the reporter marked the elisions [error]Unable to find Go version '# Single source of truth for language/tool versions (asdf/mise format). Humans and AI agents should use these versions... golang 1.26.5 nodejs 24.16.0 ...' for platform linux and architecture x64.
Common causes
go-version-file points at a file the action does not parse
The most surprising cause and the easiest to confirm, because the error quotes the file back at you. Only go.mod, go.work and .tool-versions are recognised, by exact basename. A tested-go.mod, a copied manifest under a different name or a version file in a format the action never supported all fall through to the branch that treats the whole file as a version string.
A toolchain directive in go.mod pins a patch that cannot be resolved
The toolchain line is read before the go line, so a repository that bumps toolchains for the go command is also, silently, changing what setup-go tries to install. In our experience this is the cause whenever the quoted version is a precise patch that nobody remembers putting in the workflow.
The version exists but has no build for this platform and architecture
The match is per file, not per release, so an arm64 macOS job or a Windows job can fail on a version a Linux job installs happily. The end of the message names the platform and architecture that found nothing, which is the only place this cause announces itself.
The spec is an exact patch that was never published
A typo, a patch number invented by a bump script, or a release that was pulled. This is the cause the message reads as if it always means, and it is real, but it is the one to check after the three above rather than before them.
How to fix it
Read what is inside the quotation marks before changing anything
- If the quotes hold many lines or a comment, the action fell through to its unrecognised-basename branch and the fix is the file name, not the version.
- If the quotes hold a patch nobody wrote in the workflow, search
go.modfor atoolchainline. - If the quotes hold the version you expected, read the platform and architecture at the end of the message and check that a build exists for that pair.
Give go-version-file a name the parser recognises
Point the input at a real go.mod or go.work, or copy the manifest to that basename first. A file staged under any other name is not rejected, so nothing warns you; the whole file simply becomes the spec.
```.github/workflows/ci.yml (illustrative)
- run: cp tested-go.mod "${RUNNER...

Powered by Readybot.io