-
Notifications
You must be signed in to change notification settings - Fork 528
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
Tar errors on cache restore after toolchain installation #424
Comments
Hello @matthewhughes-uw , thank you for the input. We are starting to investigate the problem. |
do you have any updates around this to share? |
@matthewhughes-uw Any updates on this? After updating to Go version: --- a/go.mod
+++ b/go.mod
@@ -1,6 +1,8 @@
module github.com/company/repo
-go 1.20
+go 1.21.1
+
+toolchain go1.21.6
require ( We start having these warnings in the build:
|
The issue seems to be caused by the setup-go being confused about the difference in "Go" version and the newly introduced "Toolchain" version.
|
Note: the toolchain download is not done by module example.com/my-mod
go 1.21.0
toolchain go1.21.1 Then if you try to run a
So unless
EDIT: I'm not sure if
(from a quick test this skipped any toolchain download) |
@matthewhughes-uw That makes sense. What I don't understand is why Go on the second download defaults back from downloading 1.21.6 to instead getting 1.21.1 again. Because if this didn't happen, then there would be no cache problem. How I solved it for now is to upgrade using Then the caching issue does not appear. |
There's a mix of
So the issue is we populate some of You could remove the |
Set the same Go version as specified in the `go.mod` because of the issue below: - actions/setup-go#424 Signed-off-by: Tiago Natel <[email protected]>
Set the same Go version as specified in the `go.mod` because of the issue below: - actions/setup-go#424 Additionally, the rand.Seed() was updated to use rand.New(rand.NewSource(seed)) because the former was removed from Go1.20. Signed-off-by: Tiago Natel <[email protected]>
Set the same Go version as specified in the `go.mod` because of the issue below: - actions/setup-go#424 Additionally, the rand.Seed() was updated to use rand.New(rand.NewSource(seed)) because the former was removed from Go1.20. Signed-off-by: Tiago Natel <[email protected]>
Set the same Go version as specified in the `go.mod` because of many similar issues related to the setup-go cache unable to work when go.mod specifies a different version. - actions/setup-go#424 Additionally, the rand.Seed() was updated to use rand.New(rand.NewSource(seed)) because the former was removed from Go1.20. Signed-off-by: Tiago Natel <[email protected]>
One way of avoiding this could be if You could do your own toolchain version parsing in an earlier step, and set an env var or something:
|
`go version` is run before downloading the cache, but if this is run with a version of `go` that triggers a Toolchain download[1], e.g. if the installed Go is 1.20.0 but `go.mod` has a toolchain directive `go1.20.1` then a toolchain is downloaded to e.g. `$GOMODCACHE/golang.org/[email protected]`, if this file already exists in the cache (e.g. this is the second run of this action we not cache invalidation) then the cache download will try and overwrite these files resulting in noisy errors like: /usr/bin/tar: ../../../go/pkg/mod/golang.org/[email protected]/lib/time/mkzip.go: Cannot open: File exists Instead, force `go` to use the local toolchain (i.e. the one the one that shipped with the go command being run) via setting the `GOTOOLCHAIN` environment variable[1]: > When GOTOOLCHAIN is set to local, the go command always runs the bundled Go toolchain. This addresses actions#424 [1] https://go.dev/doc/toolchain#select
I think this can be avoided by just telling I think there's another can of worms/separate issue around which version of Go should this action use when a |
## What this PR does / why we need it: Set the same Go version as specified in the `go.mod` because of many similar issues related to the setup-go cache unable to work when go.mod specifies a different version. - actions/setup-go#424 Additionally, the rand.Seed() was updated to use rand.New(rand.NewSource(seed)) because the former was removed from Go1.20. ## Which issue(s) this PR fixes: no ## Special notes for your reviewer: ## Does this PR introduce a user-facing change? ``` no ```
For those finding this issue, the current workaround is to just ensure that your // go.mod
go 1.22.2 # workflows/ci.yml
- uses: actions/setup-go@v5
with:
go-version: 1.22.2 |
You could also set the - name: Configure env for toolchain ignore
shell: bash
run: echo "GOTOOLCHAIN=local" >> "$GITHUB_ENV"
- name: Setup Go
uses: actions/setup-go@v5 see #460 for more details |
The same issue for me. Only go1.23 has the problem. https://github.com/timandy/gohack/actions/runs/10399737890 I found that disable cache can solve the problem. - name: Set up Go
uses: actions/setup-go@v5
with:
go-version-file: go.mod
cache: false |
Description:
When the version of Go in the
go
directive ofgo.mod
is different from the version in thetoolchain
directive there is a cache conflict which causes errors on cache extraction.Note: I think this is related to, but different from #403 since that appears to be covering the situation where some other tool is also working on the cache, but this issue is purely for the action running on a hosted runner without any additional changes to the environment etc.
Action version:
actions/setup-go@v4
Platform:
Runner type:
Tools version:
go 1.21.0
toolchain go1.21.1
Repro steps:
See repo https://github.com/matthewhughes-uw/setup-go-test/, very basic repo with a single workflow that just runs this action (https://github.com/matthewhughes-uw/setup-go-test/blob/main/.github/workflows/go.yaml):
First run of the action https://github.com/matthewhughes-uw/setup-go-test/actions/runs/6195831453/job/16821285537
go-version-file
go: downloading go1.21.1 (linux/amd64)
)../../../go/pkg/mod/golang.org/[email protected]
/home/runner/go/pkg/mod
(which contains the files above) and/home/runner/.cache/go-build
Second run of the action https://github.com/matthewhughes-uw/setup-go-test/actions/runs/6195844389/job/16821321968
../../../go/pkg/mod/golang.org/[email protected]
are already present on the machine, causing errors fromtar
Expected behavior:
Caching of the toolchain is handled gracefully, no errors between runs that don't contain any extra caching logic outside of what the action provides by default
Actual behavior:
Errors on cache extraction (see repro steps)
The text was updated successfully, but these errors were encountered: