Go: separate max supported Go version from the Go version to install#21456
Open
owen-mc wants to merge 3 commits intogithub:mainfrom
Open
Go: separate max supported Go version from the Go version to install#21456owen-mc wants to merge 3 commits intogithub:mainfrom
owen-mc wants to merge 3 commits intogithub:mainfrom
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR separates the maximum supported Go version from the Go version the autobuilder will actually install, enabling early updates to the supported-range ceiling (e.g., based on RC testing) without requiring the new Go release to exist yet.
Changes:
- Introduces
goVersionToInstallalongsidemaxGoVersionto distinguish “supported” vs “installable (released)” Go versions. - Updates autobuilder version-selection diagnostics and behavior to request
goVersionToInstallin several “best effort” paths. - Adds a small test asserting
goVersionToInstallis not newer thanmaxGoVersionand updates expectations in existing version-selection tests.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| go/extractor/autobuilder/build-environment.go | Adds goVersionToInstall and updates selection logic/diagnostic messages to install the released maximum rather than the supported maximum. |
| go/extractor/autobuilder/build-environment_test.go | Adjusts expectations to goVersionToInstall and adds a guard test for version ordering. |
You can also share your feedback on Copilot code review. Take the survey.
Comment on lines
119
to
+128
| @@ -119,8 +124,8 @@ func getVersionWhenGoModVersionTooHigh(v versionInfo) (msg string, version util. | |||
| ") is above the supported range (" + minGoVersion.String() + "-" + maxGoVersion.String() + | |||
| "). The version of Go installed in the environment (" + v.goEnvVersion.String() + | |||
| ") is below the maximum supported version (" + maxGoVersion.String() + | |||
| "). Requesting the maximum supported version of Go (" + maxGoVersion.String() + ")." | |||
| version = maxGoVersion | |||
| "). Requesting the maximum supported version of Go that has been released (" + goVersionToInstall.String() + ")." | |||
| version = goVersionToInstall | |||
| if goVersionToInstall.IsNewerThan(maxGoVersion) { | ||
| t.Errorf("goVersionToInstall (%s) should not be newer than maxGoVersion (%s).", goVersionToInstall, maxGoVersion) | ||
| } | ||
| } |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
mbg
requested changes
Mar 26, 2026
Member
mbg
left a comment
mbg
left a comment
There was a problem hiding this comment.
A few thoughts/questions/concerns here that I'd like to see addressed in the PR/code comments (or offline):
- We discussed that you should test whether recent Go toolchains even allow us to exceed the Go compiler version that our Go extractor was compiled with. Have you done that (and if so, under which circumstances does/doesn't it?)
- How does this interact with Go's own ability to install newer toolchain versions? E.g. if a new Go version is out, but we still only support the previous, and the Go toolchain downloads the new one, does that currently always break? Would this change here make any difference (beyond saving us from downloading a toolchain version we don't need)?
- Given our releases are typically every two weeks and this change requires us to manually bump the version, release it, etc. - do we think there's a big enough benefit? I.e. that a new Go version RC is released, but we are not ready to support it, but do know that we can tolerate it and ship that change faster than full support?
- I believe we have some tests for this logic in the internal repository. Will those need updating now? Are they going to break when
maxGoVersionandgoVersionToInstalldiverge for the first time?
Comment on lines
+16
to
+20
| // This can be increased before a new minor version has been released, based on testing with the release candidates. | ||
| var maxGoVersion = util.NewSemVer("1.26") | ||
|
|
||
| // This should be the maximum supported version which has been released. | ||
| var goVersionToInstall = util.NewSemVer("1.26") |
Member
There was a problem hiding this comment.
These comments should be more precise in talking about:
- Which "version" they refer to? Go toolchain? Go language? CodeQL version?
- Right now, these comments alone are not enough to understand how they interact with each other and the environment. Could you add some general comment(s) with examples along the lines of e.g. "If Go 1.26 is released, but we only support Go 1.25, then we can bump .... to 1.26 anyway if we can at least tolerate it"
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This allows us to update the max supported Go version after testing with a release candidate, but before the new version has been released. In particular, it will mean that we can merge a PR allowing us to tolerate the new version before it is released, which removes the urgency from merging the PRs to fully support and use the new version as soon as it is released.