codeql
codeql copied to clipboard
support Go 1.22.0
CodeQL runs currently fail when the go.mod is set to version 1.22.0. Go 1.22.0 was released on 2024-02-06.
The error message (as seen in this run) of the failing step ("Setup Go") is:
go: download go1.22 for linux/amd64: toolchain not available
Error: Command failed: go env GOPATH
However, if you look up earlier in the "Configure" step, there's a message emitted from identify-environment.sh:
The version of Go found in the `go.mod` file (1.22) is above the supported range (1.11-1.21). The version of Go installed in the environment (1.20.14) is below the maximum supported version (1.21). Requesting the maximum supported version of Go (1.21).
You're right that full Go 1.22 support will be coming very soon, but the existing partial support will actually work 90% of the time.
However, what's happening here is Go 1.21+ know how to themselves download a more modern version of Go if specified in the go.mod file, and will do so in response to any go command being run in the context of a go.mod specifying either a go or toolchain directive specifying a more modern version... except this requires us to specify not go 1.22 (since there is no release by that name) but go 1.22.0 (which is the name of a release). The go command will then download and use that version, and the warnings about Go 1.22 not being 100% supported yet should be irrelevant except where your code uses any language or library feature not present in Go 1.21.
I ran into the same issue during the manual build step (autobuild not supported). I worked around using this command in the workflow. Maybe this is useful to someone running into the same issue: /usr/bin/env GOTOOLCHAIN=go1.22.1+auto go build
yeah same issues with autobuild
As @smowton notes, this is a problem with Go and not CodeQL. CodeQL just uses the installed version of the Go tooling under the hood, which is what complains about the old-style versions if they appear in go.mod files and Go needs to install a newer version of Go. At the time of writing, the default version of Go that is installed on GitHub Actions runners is Go 1.21. CodeQL supports versions of Go up to and including Go 1.22. If your project uses Go 1.22, then you need to make sure it is installed on the GitHub Actions runner:
- You can do so explicitly by including a suitable
setup-gostep in your workflow. - Since Go 1.21 is already installed on the GitHub Actions runners, you can let it install Go 1.22 for you. However, for Go to be able to do this successfully, you must use the correct version format in your
go.modfiles. You can either change e.g.go 1.22togo 1.22.0or add atoolchaindirective with e.g.toolchain go1.22.0. If for some reason, you cannot correct thego.modfile to use the right version format, then @wneessen shows that this can also be done by overriding the version from thego.modfile with a suitable environment variable. This has the same effect as using the correct version format in thego.modfile. - If you are using default setup, we should now install Go 1.22 for you if you are using it, even if you are using an incorrect version format in your
go.modfile.
You can read about the change to the version format in the Go release notes for Go 1.21 and more concretely in the version format documentation.
Is this issue actually resolved? I still see errors even though this ought to be valid:
go 1.22
toolchain go1.22.0
Hi @ynori7 👋
The issue is resolved and there wasn't really one to begin with (see our previous comments). There is an issue with the Go tooling, not CodeQL. The warning you are seeing on the tool status page is one we added recently that detects the circumstances under which the Go tools break and provides an explanation as well as instructions for how to avoid their issue.
If you have a toolchain directive in your go.mod file, you should not be seeing that warning, however. Note that we check all go.mod files in the repository for the problem. Are you sure that the warning relates to the go.mod file you showed the contents of? Does this happen in a public repository, and if so, can you link to it? Does the associated scan actually fail (A warning is not an error.)?
Yes, when clicking "go to file" it takes me to a file which states:
go 1.22
toolchain go1.22.0
I am using a self-hosted runner however. The output from the run is:
Analysis produced the following diagnostic information:
- Invalid Go toolchain version (1 result):
* go.mod#L0C0:0: As of Go 1.21, toolchain versions [must use the 1.N.P syntax](https://go.dev/doc/toolchain#version).
`1.22` in `go.mod` does not match this syntax and there is no additional `toolchain` directive, which may cause some `go` commands to fail.
However the build begins with Autobuilder was built with go1.22.1, environment has go1.22.2. Do I maybe need to update something in my runner to support go v1.22?
@ynori7: Thanks for the extra information. Two things here:
-
I have experimented a bit since my last message and think that there might be circumstances where our new diagnostic gets emitted, even though a
toolchaindirective is present. This seems to be due to some unexpected behaviour in themodfilelibrary package. I'll need to investigate this further to see whether we are doing something wrong or there is an upstream problem. -
I still can't tell from the information you provided whether your analysis actually succeeds or not. Diagnostics, especially warnings, are not indicative of any failures. They exist to help diagnose problems when there is a failure. Does the overall workflow fail? Are there any errors you haven't shown that you are concerned about?
If there is no failure, then you can just ignore the diagnostic.
However the build begins with
Autobuilder was built with go1.22.1, environment has go1.22.2. Do I maybe need to update something in my runner to support go v1.22?
This is just normal output that is produced for every run.
Thanks @mbg, as far as I can tell, the run succeeded. Expanded a bit I see:
CodeQL scanned 20 out of 25 Go files in this invocation. Typically CodeQL is configured to analyze a single CodeQL language per invocation, so check other invocations to determine overall coverage information.
Analysis produced the following diagnostic information:
- Invalid Go toolchain version (1 result):
* go.mod#L0C0:0: As of Go 1.21, toolchain versions [must use the 1.N.P syntax](https://go.dev/doc/toolchain#version).
`1.22` in `go.mod` does not match this syntax and there is no additional `toolchain` directive, which may cause some `go` commands to fail.
Exporting results to SARIF v2.1.0...
Exported results to SARIF v2.1.0 (121ms).
I don't see any indication that the scan failed.
That does look like a successful run to me, so there should be nothing to worry about.
I have a PR to fix the cause for the erroneous diagnostic, so once that's merged, has found it's way into a CodeQL release, and you have run an analysis with it, this diagnostic should disappear from your tool status page.
Thanks for bringing this to our attention!