Improve the messages reported for the user when cachi2 check/download the toolchain

[cmoulliard]

Issue

This is not evident for the end user to understand sometimes the internal logic used by Cachi2 to check/download the go SDK

See some examples hereafter

Using go version 1.18

Repository of the project: https://github.com/redhat-buildpacks/fork-jam/blob/main/go.mod#L3
branch: main
go.mod version: 1.18

Questions:

• Why is cachi2 using go 1.20 and not 1.18 ?
• Why is cachi2 not complaining about the fact that the version don't include the patch number 1.18.0 ?

[prefetch-dependencies] 2024-10-16 06:42:37,795 DEBUG Matched Go version 1.18 on go.mod line 2: 'go 1.18
[prefetch-dependencies] 2024-10-16 06:42:37,796 INFO go.mod reported versions: '1.18'[go], '-'[toolchain]
[prefetch-dependencies] 2024-10-16 06:42:37,796 DEBUG Trying to locate Go toolchain at '/usr/local/go/go1.20/bin/go': SUCCESS
[prefetch-dependencies] 2024-10-16 06:42:37,796 INFO Using Go release: go1.20

Using go version 1.23.0 =>

Repository of the project: https://github.com/redhat-buildpacks/fork-libpak/blob/bump-go-version/go.mod#L3
branch: bump-go-version
go.mod version: 1.23.0

Question: Why is cachi2 using go 1.21 and not 1.23 ?

[prefetch-dependencies] 2024-10-16 06:46:23,120 DEBUG Matched Go version 1.23.0 on go.mod line 2: 'go 1.23.0
[prefetch-dependencies] 2024-10-16 06:46:23,120 INFO go.mod reported versions: '1.23.0'[go], '-'[toolchain]
[prefetch-dependencies] 2024-10-16 06:46:23,121 DEBUG Trying to locate Go toolchain at '/usr/local/go/go1.21.0/bin/go': FAIL
[prefetch-dependencies] 2024-10-16 06:46:23,123 DEBUG Trying to locate Go toolchain at '/root/.cache/cachi2/go/go1.21.0/bin/go': FAIL
[prefetch-dependencies] 2024-10-16 06:46:23,123 DEBUG Desired toolchain 'go1.21.0' not found, will download it lazily
[prefetch-dependencies] 2024-10-16 06:46:23,123 INFO Using Go release: go1.21.0
[prefetch-dependencies] 2024-10-16 06:46:23,124 DEBUG Installing Go go1.21.0 toolchain shim from 'golang.org/dl/go1.21.0@latest'

Using go 1.22.0

Repository of the project: https://github.com/redhat-buildpacks/fork-pack/blob/bump-go-version/go.mod#L146
branch: bump-go-version
go.mod version: 1.22.0

This is not clear for a user to understand why cachi2 fails to download the toolchain 1.22. A more user friendly message should be
logged to explain the root cause

[prefetch-dependencies] 2024-10-16 06:48:14,032 INFO Fetching the gomod dependencies at subpath pack
[prefetch-dependencies] 2024-10-16 06:48:14,033 INFO Fetching the gomod dependencies at the "pack" directory
[prefetch-dependencies] 2024-10-16 06:48:14,033 DEBUG Running '['go', 'env', 'GOWORK']'
[prefetch-dependencies] 2024-10-16 06:48:14,544 ERROR The command "go env GOWORK" failed
[prefetch-dependencies] 2024-10-16 06:48:14,544 ERROR STDERR:
[prefetch-dependencies] go: downloading go1.22 (linux/amd64)
[prefetch-dependencies] go: download go1.22 for linux/amd64: toolchain not available
[prefetch-dependencies] 2024-10-16 06:48:14,545 DEBUG Running '['go', 'clean', '-modcache']'
[prefetch-dependencies] 2024-10-16 06:48:30,510 ERROR PackageManagerError: Go execution failed: `go env GOWORK` failed with rc=1
[prefetch-dependencies] Error: PackageManagerError: Go execution failed: `go env GOWORK` failed with rc=1
[prefetch-dependencies]   The cause of the failure could be:
[prefetch-dependencies]   - something is broken in Cachi2
[prefetch-dependencies]   - something is wrong with your repository
[prefetch-dependencies]   - communication with an external service failed (please try again)
[prefetch-dependencies]   The output of the failing command should provide more details, please check the logs.

My issue is related too to this one: #550

[eskultety]

• Why is cachi2 using go 1.20 and not 1.18 ?

Because 1.20 handles all versions up this one equally, it is 1.21 that introduced changes that somewhat break backwards compatibility when it comes to processing dependencies (i.e. not related to compiling modules) and so we decided to pre-install 1.20 instead of trying to process old Go projects with exactly the same language version of Go as it's pointless (old Go's didn't pose the strict minimum toolchain requirements on projects and their dependencies).

• Why is cachi2 not complaining about the fact that the version don't include the patch number 1.18.0

That is on purpose, because the format change of the version string X.Y.Z came with 1.21 and so if you tried to use 1.18.0 and tried running any go command over your go.mod file it would fail to parse it. So we had to carefully work around this problem transparently.

Why is cachi2 using go 1.21 and not 1.23 ?

It is, you just don't see it / can't figure it out from the logs (#550), but it does use 1.23 ! What happens here is that we only log the toolchain that we found, but not the one that ends up being used by Go, why? Because we're not in charge of using that newer toolchain, we just set GOTOOLCHAIN=auto and run a particular go command which will look at that env variable, fetch it automatically and use it to complete the operation - as you can see, it's not easy to log usage of a toolchain that doesn't exist prior to running the command and has already been used by the end of that command's execution so we'll have to artificially mangle the logs to reflect on this fact.

This is not clear for a user to understand why cachi2 fails to download the toolchain 1.22. A more user friendly message should be
logged to explain the root cause

Agreed, but keep in mind that sometimes even Go fails silently with some operations (parameter combinations), especially when automatic toolchain fetching is involved and so we may not always be able to extract the info you'd like to see because even we don't have it.

[eskultety]

It is, you just don't see it / can't figure it out from the logs (#550), but it does use 1.23 !

It's also worth mentioning that we're keeping 1.21 pre-installed due to the need to refactor big parts of the whole gomod module's logic, which is due, which will happen over time, but thanks to the GOTOOLCHAIN=auto mechanism isn't as pressing to us as other issues at the moment, simply because that 1.21.0 pre-installed toolchain ends up being just an entrypoint placeholder for 99% cases and the correct toolchain will be fetched by Go itself on demand.

[eskultety]

@cmoulliard unless #684 (comment) doesn't answer the main pain points you raised would you agree to closing this one as a duplicate of #550?

[cmoulliard]

@cmoulliard unless #684 (comment) doesn't answer the main pain points

That adresses the questions but not really the issue itself as no code/PR has been submitted to improve the messages displayed and to let the users to figure out what they should do

[cmoulliard]

closing this one as a duplicate of #550?

If the issue 550 also covers the content of my issue, then I'm fine to close it but AFAIK the issue of 550 only covers a subset