You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When Go 1.21 was released it changed the game significantly because it started enforcing the 'go X.Y.Z' line in one's go.mod file as the minimum required version to process/build a project. That lead to some undesirable side effects of newer Go toolchains dirtying users source repositories that still used old Go releases with upgrade-related cruft. The bandaid we applied at the time was to start supporting 2 Go toolchain streams - one for legacy projects and one for 1.21+ based projects. We build it around the 'GOTOOLCHAIN=auto' variable which let us to download any user desired toolchain on demand during prefetch automatically. Therefore, with the 1.21+ toolchains we are always fixed a 0th release of a particular language release, e.g. 1.21.0. The problem however is that the code is somewhat buggy.
It is time for us to get rid of the legacy toolchain (EOL in upstream) and only process input repositories with a single one. Addressing this should include:
querying all installed go binaries on the system (system PATH, our locations, user HOME path)
query the toolchains early in the prefetch process (i.e. before _fetch_gomod)
pick the best toolchain for the job based on the go.mod contents and on results from step 2.
Log the actual toolchain version that is to be used AND log both toolchain versions if we don't have the desired one and go will need to download it automatically for us
Let dependabot automatically update the micro release of the pre-installed toolchain in our image (i.e. decrease our dependence on GOTOOLCHAIN=auto)
Drop the legacy 1.20 toolchain support and its install from our container image
The text was updated successfully, but these errors were encountered:
When Go 1.21 was released it changed the game significantly because it started enforcing the 'go X.Y.Z' line in one's go.mod file as the minimum required version to process/build a project. That lead to some undesirable side effects of newer Go toolchains dirtying users source repositories that still used old Go releases with upgrade-related cruft. The bandaid we applied at the time was to start supporting 2 Go toolchain streams - one for legacy projects and one for 1.21+ based projects. We build it around the 'GOTOOLCHAIN=auto' variable which let us to download any user desired toolchain on demand during prefetch automatically. Therefore, with the 1.21+ toolchains we are always fixed a 0th release of a particular language release, e.g. 1.21.0. The problem however is that the code is somewhat buggy.
It is time for us to get rid of the legacy toolchain (EOL in upstream) and only process input repositories with a single one. Addressing this should include:
_fetch_gomod
)go
will need to download it automatically for usGOTOOLCHAIN=auto
)1.20
toolchain support and its install from our container imageThe text was updated successfully, but these errors were encountered: