Tar errors on cache restore after toolchain installation #424
Comments
matthewhughes-uw
changed the title
|
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.1Then 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 <t.nateldemoura@gmail.com>
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 <t.nateldemoura@gmail.com>
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 <t.nateldemoura@gmail.com>
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 <t.nateldemoura@gmail.com>
|
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/toolchain@v0.0.1-go1.21.1.linux-amd64`, 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/toolchain@v0.0.1-go1.21.6.linux-amd64/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@v5see #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
godirective ofgo.modis different from the version in thetoolchaindirective 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@v4Platform:
Runner type:
Tools version:
go 1.21.0toolchain go1.21.1Repro 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-filego: downloading go1.21.1 (linux/amd64))../../../go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.1.linux-amd64/home/runner/go/pkg/mod(which contains the files above) and/home/runner/.cache/go-buildSecond run of the action https://github.com/matthewhughes-uw/setup-go-test/actions/runs/6195844389/job/16821321968
../../../go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.1.linux-amd64are already present on the machine, causing errors fromtarExpected 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: