Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gomod: go1.21 toolchain not available #7895

Closed
1 task done
pierrre opened this issue Aug 24, 2023 · 12 comments · Fixed by #8044
Closed
1 task done

gomod: go1.21 toolchain not available #7895

pierrre opened this issue Aug 24, 2023 · 12 comments · Fixed by #8044
Assignees
Labels
L: go:modules Golang modules T: bug 🐞 Something isn't working

Comments

@pierrre
Copy link

pierrre commented Aug 24, 2023

Is there an existing issue for this?

  • I have searched the existing issues

Package ecosystem

gomod

Package manager version

No response

Language version

1.21

Manifest location and content before the Dependabot update

No response

dependabot.yml content

version: 2
updates:
  - package-ecosystem: "gomod"
    directory: "/"
    schedule:
      interval: "daily"
      time: "08:00"
      timezone: "Europe/Paris"
    allow:
      - dependency-type: "direct"
      - dependency-type: "indirect"
      - dependency-type: "all"
    reviewers:
      - "pierrre"

Updated dependency

No response

What you expected to see, versus what you actually saw

My go.mod contains this + some dependencies:

module github.com/pierrre/go-libs

go 1.21

Yesterday, dependabot was updating my dependencies without any issue.

Today it's failing with this error message (I didn't change anything on my side):

Dependabot can't parse your go.mod
Dependabot failed to update your dependencies because there was an error parsing the go.mod found at /go.mod.

Dependabot encountered the following error:

go: downloading go1.21 (linux/amd64)
go: download go1.21 for linux/amd64: toolchain not available

and logs

 proxy | 2023/08/24 06:55:13 proxy starting, commit: 9833ecd82095ae7ce56480f9538522148bf46c95
  proxy | 2023/08/24 06:55:13 Listening (:1080)
updater | 2023-08-24T06:55:13.604365688 [713250698:main:WARN:src/devices/src/legacy/serial.rs:222] Detached the serial input due to peer close/error.
updater | time="2023-08-24T06:55:15Z" level=info msg="guest starting" commit=b5ee63832e5412942127524d25c88400573f5df7
updater | time="2023-08-24T06:55:15Z" level=info msg="starting job..." fetcher_timeout=10m0s job_id=713250698 updater_timeout=45m0s updater_version=1cc46f801e61cf6988ef5e35fc16f54675a17c52-gomod
updater | 2023/08/24 06:55:16 INFO Raven 3.1.2 ready to catch errors
updater | 2023/08/24 06:55:17 INFO <job_713250698> Starting job processing
  proxy | 2023/08/24 06:55:17 [002] GET https://github.com:443/pierrre/go-libs/info/refs?service=git-upload-pack
  proxy | 2023/08/24 06:55:17 [002] * authenticating git server request (host: github.com)
  proxy | 2023/08/24 06:55:17 [002] 200 https://github.com:443/pierrre/go-libs/info/refs?service=git-upload-pack
  proxy | 2023/08/24 06:55:17 [004] POST https://github.com:443/pierrre/go-libs/git-upload-pack
  proxy | 2023/08/24 06:55:17 [004] * authenticating git server request (host: github.com)
  proxy | 2023/08/24 06:55:17 [004] 200 https://github.com:443/pierrre/go-libs/git-upload-pack
  proxy | 2023/08/24 06:55:17 [006] POST https://github.com:443/pierrre/go-libs/git-upload-pack
  proxy | 2023/08/24 06:55:17 [006] * authenticating git server request (host: github.com)
  proxy | 2023/08/24 06:55:18 [006] 200 https://github.com:443/pierrre/go-libs/git-upload-pack
updater | 2023/08/24 06:55:18 INFO <job_713250698> Finished job processing
updater | time="2023-08-24T06:55:18Z" level=info msg="task complete" container_id=job-713250698-file-fetcher exit_code=0 job_id=713250698 step=fetcher
updater | 2023/08/24 06:55:19 INFO Raven 3.1.2 ready to catch errors
updater | 2023/08/24 06:55:19 INFO <job_713250698> Starting job processing
  proxy | 2023/08/24 06:55:20 [010] GET https://proxy.golang.org:443/golang.org/toolchain/@v/v0.0.1-go1.21.linux-amd64.zip
  proxy | 2023/08/24 06:55:21 [010] 404 https://proxy.golang.org:443/golang.org/toolchain/@v/v0.0.1-go1.21.linux-amd64.zip
  proxy | 2023/08/24 06:55:21 [012] GET https://golang.org:443/toolchain?go-get=1
  proxy | 2023/08/24 06:55:21 [012] 200 https://golang.org:443/toolchain?go-get=1
  proxy | 2023/08/24 06:55:21 [014] GET https://go.dev:443/dl/mod/golang.org/toolchain/@v/v0.0.1-go1.21.linux-amd64.zip
  proxy | 2023/08/24 06:55:21 [014] 302 https://go.dev:443/dl/mod/golang.org/toolchain/@v/v0.0.1-go1.21.linux-amd64.zip
  proxy | 2023/08/24 06:55:22 [016] GET https://dl.google.com:443/go/v0.0.1-go1.21.linux-amd64.zip
  proxy | 2023/08/24 06:55:22 [016] 404 https://dl.google.com:443/go/v0.0.1-go1.21.linux-amd64.zip
updater | 2023/08/24 06:55:22 INFO <job_713250698> Finished job processing
updater | 2023/08/24 06:55:22 INFO Results:
updater | Dependabot encountered '1' error(s) during execution, please check the logs for more details.
updater | +-------------------------------+
updater | |            Errors             |
updater | +-------------------------------+
updater | | dependency_file_not_parseable |
updater | +-------------------------------+
updater | time="2023-08-24T06:55:22Z" level=info msg="task complete" container_id=job-713250698-updater exit_code=0 job_id=713250698 step=updater

Native package manager behavior

It's updating dependencies without any issues.

It doesn't attempt to download a toolchain.

Images of the diff or a link to the PR, issue, or logs

No response

Smallest manifest that reproduces the issue

module github.com/pierrre/go-libs

go 1.21
@pierrre pierrre added the T: bug 🐞 Something isn't working label Aug 24, 2023
@pierrre
Copy link
Author

pierrre commented Aug 24, 2023

I guess I could change my go.mod, and use go 1.21.0 instead of go 1.21.
Then downloading the file would work.
But it doesn't explain why the behavior changed since yesterday.
Why does it need to download a toolchain ?
And why is it working properly on my local computer ?

@jakecoffman
Copy link
Member

jakecoffman commented Aug 24, 2023

This is a result of the changes in #7884.

It's reproducible by running this in your repo:

$ GOTOOLCHAIN="go1.20+auto" go version
go: downloading go1.21 (darwin/arm64)
go: download go1.21 for darwin/arm64: toolchain not available

Per the docs, it seems like the Go tooling is trying to use 1.21 as a toolchain:

For example, a go.mod that says go 1.21.0 with no toolchain line is interpreted as if it had a toolchain go1.21.0 line.

but 1.21 is not a valid toolchain:

The standard Go toolchains are named goV where V is a Go version denoting a beta release, release candidate, or release. For example, go1.21rc1 and go1.21.0 are toolchain names; go1.21 and go1.22 are not (the initial releases are go1.21.0 and go1.22.0), but go1.20 and go1.19 are.

It seems like the right thing to do here is have Dependabot run with GOTOOLCHAIN="go1.20+path" which will fallback to 1.21 which is currently installed. That seems to fix it.

@jakecoffman jakecoffman added the L: go:modules Golang modules label Aug 24, 2023
@pierrre
Copy link
Author

pierrre commented Aug 24, 2023

Is there something I can do on my side to fix this error ?
Should I update my go.mod ?

@jakecoffman
Copy link
Member

@pierrre Dependabot should work correctly with a toolchain directive or update the go directive as you said above. So if you want a fix right away go ahead and do that.

@jakecoffman
Copy link
Member

I was mistaken and GOTOOLCHAIN="go1.20+path" won't work either. go1.21 just isn't a valid toolchain, but it is a valid go directive.

It looks like someone has filed an issue upstream, lets see how this pans out before I make any more changes: golang/go#62278

@pierrre
Copy link
Author

pierrre commented Aug 28, 2023

In my projects I've updated go.mod from go 1.21 to go 1.21.0, and it seems to work.
Dependabot is able to update my dependencies again.

@mrkagelui
Copy link

what should we do? having go 1.21.0 in go.mod would mean the project requires specifically 1.21.0 though, what if people want to require just go 1.21?

@pierrre
Copy link
Author

pierrre commented Aug 30, 2023

@mrkagelui

what should we do? having go 1.21.0 in go.mod would mean the project requires specifically 1.21.0 though, what if people want to require just go 1.21?

https://go.dev/doc/modules/gomod-ref#go-syntax

The minimum version of Go required to compile packages in this module.

@mrkagelui
Copy link

oh I understand it's a minimum version, I mean, "minimum 1.21" and "minimum 1.21.0" is still a bit different.

@mrkagelui
Copy link

mrkagelui commented Sep 10, 2023

oh I understand it's a minimum version, I mean, "minimum 1.21" and "minimum 1.21.0" is still a bit different.

now that 1.21.1 is available, it's easier to explain myself.

I meant, iinw (please let me know otherwise), if let's say go 1.21.1 is specified and the project actually needs nothing more than 1.21.0, if a develop has 1.21.0, go tool chain will need to download 1.21.1 for them before building it.

or the other way around, if go 1.21.0 is specified while the person has go 1.21.1, another version would need to be downloaded, while it's actually more correct for the project to specify go 1.21, and the additional download can be avoided.

aleoli added a commit to aleoli/liqo that referenced this issue Sep 11, 2023
adamjensenbot pushed a commit to aleoli/liqo that referenced this issue Sep 11, 2023
aleoli added a commit to aleoli/liqo that referenced this issue Sep 11, 2023
aleoli added a commit to aleoli/liqo that referenced this issue Sep 11, 2023
aleoli added a commit to aleoli/liqo that referenced this issue Sep 11, 2023
adamjensenbot pushed a commit to liqotech/liqo that referenced this issue Sep 11, 2023
@fasmat
Copy link

fasmat commented Sep 15, 2023

Will dependabot be updated to be able to parse go 1.21 so we don't have to specify a minor version?

@jakecoffman
Copy link
Member

We're now setting GOTOOLCHAIN="local" in Ruby code to sidestep this issue.

bors bot pushed a commit to spacemeshos/go-spacemesh that referenced this issue Sep 19, 2023
## Motivation
`dependabot` has troubles parsing a `go.mod` file with `go 1.21` if it doesn't specify a patch version. (see dependabot/dependabot-core#7895). This PR fixes the issue.

Summary from https://go.dev/doc/toolchain:
The version in `go.mod` now specifies the **minimum** version of go that is required to build the module and **must include** a patch version. Additionally if the module or any of its dependencies require a newer version of go than the compiler the compiler will auto download the required `toolchain`, i.e. the compiler will essentially download the minimum required version of itself if it's older than the newest versions specified by the module or its dependencies.

`go 1.21.0` instructs the compiler to use at least version 1.21.0 or any newer version (if specified by e.g. a dependency) when building the module. We do not need to update the patch version with every new release of go unless go-spacemesh is affected by a bug that was fixed in that release.

`actions/setup-go` doesn't use the newest patch version with `check-version` when it is already specified. With the new behavior this is also not needed, as the `go build` command will automatically download the required toolchain if needed. In case we still want to automatically use the newest patch version to build our binaries we have to set `1.21` and `check-version=true` explicitly for `actions/setup-go`.

## Changes
- specify a minor version in `go.mod` until `dependabot` is able to parse `go 1.21`
- Update `ci.yml` to explicitly use the newest patch version of 1.21 when building go-spacemesh.

## Test Plan
n/a

## TODO
<!-- This section should be removed when all items are complete -->
- [x] Explain motivation or link existing issue(s)
- [x] Test changes and document test plan
- [x] Update documentation as needed
- [x] Update [changelog](../CHANGELOG.md) as needed
bors bot pushed a commit to spacemeshos/go-spacemesh that referenced this issue Sep 19, 2023
## Motivation
`dependabot` has troubles parsing a `go.mod` file with `go 1.21` if it doesn't specify a patch version. (see dependabot/dependabot-core#7895). This PR fixes the issue.

Summary from https://go.dev/doc/toolchain:
The version in `go.mod` now specifies the **minimum** version of go that is required to build the module and **must include** a patch version. Additionally if the module or any of its dependencies require a newer version of go than the compiler the compiler will auto download the required `toolchain`, i.e. the compiler will essentially download the minimum required version of itself if it's older than the newest versions specified by the module or its dependencies.

`go 1.21.0` instructs the compiler to use at least version 1.21.0 or any newer version (if specified by e.g. a dependency) when building the module. We do not need to update the patch version with every new release of go unless go-spacemesh is affected by a bug that was fixed in that release.

`actions/setup-go` doesn't use the newest patch version with `check-version` when it is already specified. With the new behavior this is also not needed, as the `go build` command will automatically download the required toolchain if needed. In case we still want to automatically use the newest patch version to build our binaries we have to set `1.21` and `check-version=true` explicitly for `actions/setup-go`.

## Changes
- specify a minor version in `go.mod` until `dependabot` is able to parse `go 1.21`
- Update `ci.yml` to explicitly use the newest patch version of 1.21 when building go-spacemesh.

## Test Plan
n/a

## TODO
<!-- This section should be removed when all items are complete -->
- [x] Explain motivation or link existing issue(s)
- [x] Test changes and document test plan
- [x] Update documentation as needed
- [x] Update [changelog](../CHANGELOG.md) as needed
bors bot pushed a commit to spacemeshos/go-spacemesh that referenced this issue Sep 19, 2023
## Motivation
`dependabot` has troubles parsing a `go.mod` file with `go 1.21` if it doesn't specify a patch version. (see dependabot/dependabot-core#7895). This PR fixes the issue.

Summary from https://go.dev/doc/toolchain:
The version in `go.mod` now specifies the **minimum** version of go that is required to build the module and **must include** a patch version. Additionally if the module or any of its dependencies require a newer version of go than the compiler the compiler will auto download the required `toolchain`, i.e. the compiler will essentially download the minimum required version of itself if it's older than the newest versions specified by the module or its dependencies.

`go 1.21.0` instructs the compiler to use at least version 1.21.0 or any newer version (if specified by e.g. a dependency) when building the module. We do not need to update the patch version with every new release of go unless go-spacemesh is affected by a bug that was fixed in that release.

`actions/setup-go` doesn't use the newest patch version with `check-version` when it is already specified. With the new behavior this is also not needed, as the `go build` command will automatically download the required toolchain if needed. In case we still want to automatically use the newest patch version to build our binaries we have to set `1.21` and `check-version=true` explicitly for `actions/setup-go`.

## Changes
- specify a minor version in `go.mod` until `dependabot` is able to parse `go 1.21`
- Update `ci.yml` to explicitly use the newest patch version of 1.21 when building go-spacemesh.

## Test Plan
n/a

## TODO
<!-- This section should be removed when all items are complete -->
- [x] Explain motivation or link existing issue(s)
- [x] Test changes and document test plan
- [x] Update documentation as needed
- [x] Update [changelog](../CHANGELOG.md) as needed
bors bot pushed a commit to spacemeshos/go-spacemesh that referenced this issue Sep 19, 2023
## Motivation
`dependabot` has troubles parsing a `go.mod` file with `go 1.21` if it doesn't specify a patch version. (see dependabot/dependabot-core#7895). This PR fixes the issue.

Summary from https://go.dev/doc/toolchain:
The version in `go.mod` now specifies the **minimum** version of go that is required to build the module and **must include** a patch version. Additionally if the module or any of its dependencies require a newer version of go than the compiler the compiler will auto download the required `toolchain`, i.e. the compiler will essentially download the minimum required version of itself if it's older than the newest versions specified by the module or its dependencies.

`go 1.21.0` instructs the compiler to use at least version 1.21.0 or any newer version (if specified by e.g. a dependency) when building the module. We do not need to update the patch version with every new release of go unless go-spacemesh is affected by a bug that was fixed in that release.

`actions/setup-go` doesn't use the newest patch version with `check-version` when it is already specified. With the new behavior this is also not needed, as the `go build` command will automatically download the required toolchain if needed. In case we still want to automatically use the newest patch version to build our binaries we have to set `1.21` and `check-version=true` explicitly for `actions/setup-go`.

## Changes
- specify a minor version in `go.mod` until `dependabot` is able to parse `go 1.21`
- Update `ci.yml` to explicitly use the newest patch version of 1.21 when building go-spacemesh.

## Test Plan
n/a

## TODO
<!-- This section should be removed when all items are complete -->
- [x] Explain motivation or link existing issue(s)
- [x] Test changes and document test plan
- [x] Update documentation as needed
- [x] Update [changelog](../CHANGELOG.md) as needed
wjam added a commit to wjam/dotfiles that referenced this issue Oct 4, 2023
Dependabot no longer requires the patch version

dependabot/dependabot-core#7895
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
L: go:modules Golang modules T: bug 🐞 Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants