I have the same issue here. Running tests on a linux (ubuntu based).
It only happens when a use the flag coverpkg. I have managed to "solve" it on an very bad way, creating an empty test file in packages that don't have tests (removed the files paths) ``` open /tmp/go-build2070237917/b334/covmeta.ce414c14907a52c0962d732a8a53fd8b6639b1f9a004b9c6e110921165bab8c3: no such file or directory open /tmp/go-build2070237917/b335/covmeta.41db8a5854133f388ac5e1dae6628818f4bfb391b0fed738b0e33c2fa26dd79b: no such file or directory ... ... .... ``` Em quinta-feira, 8 de fevereiro de 2024 às 16:41:18 UTC-3, Martin Schallnahs escreveu: > Hey Brian, > > dont get me wrong! > > My usual setup is Continuous Integration Pipeline running in Linux VMs > which, in case of my golang projects, start fresh golang docker container > images from DockerHub. > In case of this problem I used golang:1.22.0-alpine3.19 and golang:1.22.0 > (debian basd). > For both I have the problem I describe. > I just wanted to show, that its not a Docker problem and used my local > Windows machine do prove that. > > I grabbed my Macbook Pro (Intel), installed freshly Golang 1.22.0 and run > the mentioned go test command on the reproducer, and for me here the > problem also gets triggered. > As you explained I use the corrected reproducer, with the Test not > failing, and have "go 1.22.0" in the go.mod. > > > $ go version > go version go1.22.0 darwin/amd64 > > $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... > -covermode count > example.com/m: open > /var/folders/dm/k73ydgtx15l7dzwc3qk_wmhc0000gn/T/go-build3097649140/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72: > > no such file or directory > > === RUN TestHelloer > --- PASS: TestHelloer (0.00s) > PASS > coverage: 100.0% of statements in ./internal/... > ok example.com/m/internal 0.261s coverage: 100.0% of statements in > ./internal/… > > > Bit confusing, that it works for you though. > On Thursday, February 8, 2024 at 6:11:15 PM UTC+1 Brian Candler wrote: > >> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... >> -covermode count || echo "flaky:$?" >> example.com/m: open >> /tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72: >> >> no such file or directory >> >> C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out >> -coverpkg=./internal/... -covermode count >> example.com/m: open >> C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72: >> >> The system cannot find the file specified. >> >> Those look like the underlying errors causing the exit code 1. But it >> works fine for me under both Linux and macOS, as long as I have "go 1.22.0" >> in go.mod. Maybe someone who knows more about Windows can help? >> >> On Thursday 8 February 2024 at 17:03:18 UTC Martin Schallnahs wrote: >> >>> Hi Brian, >>> >>> thanks for checking out, yes that I wanted also to write you. >>> We need it currently in our CI as some dependency scanner tool does not >>> work with the "go X.Y.Z." syntax, but I tried, and for my problem it did >>> not was the cause. >>> >>> >>> > If a test fails, I would expect it to terminate with an error (exit >>> code 1 in this case). >>> >>> See my second mail, the test case should not fail, it was kinda a typo >>> (tried to shorten the reproducer to much in my first mail). >>> >>> > If I run your reproducer locally (not in Docker) with the modified >>> TestHelloer, it works fine(*) and gives me an exit code of 0 >>> >>> Yes, when I run it with golang 1.21.7 it works fine as well, as my >>> problem statement is about golang 1.22.0. >>> >>> > Therefore, if your problem only occurs when using Docker, then you >>> should provide a docker-based reproducer (including the Dockerfile) >>> >>> Happens locally as well. And in my original setup it was using a fresh >>> docker container from golang (in an CI/GitLab pipeline) and did this: >>> >>> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... >>> -covermode count || echo "flaky:$?" >>> example.com/m: open >>> /tmp/go-build2233205084/b002/covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72: >>> >>> no such file or directory >>> >>> === RUN TestHelloer >>> --- PASS: TestHelloer (0.00s) >>> PASS >>> coverage: 100.0% of statements in ./internal/... >>> ok example.com/m/internal 0.004s coverage: 100.0% of statements in >>> ./internal/... >>> flaky:1 >>> $ go tool cover -html=coverage.out -o coverage.html >>> $ go tool cover -func=coverage.out >>> example.com/m/internal/helloer.go:3: Helloer 100.0% >>> total: (statements) 100.0% >>> >>> >>> But I just tried it locally (Windows) and there it happens as well: >>> >>> C:\dev\git\golang-test-cover>go test -v ./... -coverprofile=coverage.out >>> -coverpkg=./internal/... -covermode count >>> example.com/m: open >>> C:\Users\A1524415\AppData\Local\Temp\go-build2423189316\b002\covmeta.f6e4431d5ec1fd71f02b3ce4e56eb691a86525173d917007425576a7d9db7c72: >>> >>> The system cannot find the file specified. >>> >>> === RUN TestHelloer >>> --- PASS: TestHelloer (0.00s) >>> PASS >>> coverage: 100.0% of statements in ./internal/... >>> ok example.com/m/internal 15.260s coverage: 100.0% of statements >>> in ./internal/... >>> >>> >>> So for now I checked it on: >>> - windows >>> - debian (via docker container) >>> - alpine (via docker container) >>> >>> All with 1.22.0. >>> >>> > since you say that the coverage file is created, and presumably you >>> would have noticed the "toolchain not available" error message. In any >>> case, you're using a base image with go 1.22.0. >>> >>> Exactly. >>> As seen in the output above, further commands (go tool cover) using the >>> coverage.out work fine. >>> >>> On Thursday 8 February 2024 at 10:46:44 UTC+1 Brian Candler wrote: >>> >>>> I found the solution to the "toolchain not available" problem: put "go >>>> 1.22.0" instead of "go 1.22" in go.mod. Clues picked up from #62278 >>>> <https://github.com/golang/go/issues/62278>. >>>> >>>> It's confusing for people who've been using go for a while though, when >>>> go.mod used to contain "go X.Y" and it was invalid to put "go X.Y.Z". Now >>>> that appears to have swapped around >>>> <https://github.com/golang/go/issues/62278#issuecomment-1698829945>. >>>> >>>> On Thursday 8 February 2024 at 08:30:25 UTC Brian Candler wrote: >>>> >>>>> Is it a bug or exepected behaviour? >>>>> >>>>> >>>>> If a test fails, I would expect it to terminate with an error (exit >>>>> code 1 in this case). >>>>> >>>>> If I run your reproducer locally (not in Docker) with the modified >>>>> TestHelloer, it works fine(*) and gives me an exit code of 0: >>>>> >>>>> % go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... >>>>> -covermode count >>>>> ? example.com/m [no test files] >>>>> === RUN TestHelloer >>>>> --- PASS: TestHelloer (0.00s) >>>>> PASS >>>>> >>>>> coverage: 100.0% of statements in ./internal/... >>>>> ok example.com/m/internal 0.135s coverage: 100.0% of statements in >>>>> ./internal/... >>>>> % echo $? >>>>> 0 >>>>> >>>>> Therefore, if your problem only occurs when using Docker, then you >>>>> should provide a docker-based reproducer (including the Dockerfile) >>>>> >>>>> (*) However, I had to change the go.mod file to say version 1.21. If >>>>> it says 1.22, I get an error. >>>>> >>>>> Under Linux (go1.21.7): >>>>> >>>>> $ go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... >>>>> -covermode count >>>>> go: downloading go1.22 (linux/amd64) >>>>> go: download go1.22 for linux/amd64: toolchain not available >>>>> >>>>> Under macOS (go1.21.6): >>>>> >>>>> % go test -v ./... -coverprofile=coverage.out -coverpkg=./internal/... >>>>> -covermode count >>>>> go: downloading go1.22 (darwin/arm64) >>>>> go: download go1.22 for darwin/arm64: toolchain not available >>>>> >>>>> I don't *think* this is the same problem as you're seeing, since you >>>>> say that the coverage file is created, and presumably you would have >>>>> noticed the "toolchain not available" error message. In any case, you're >>>>> using a base image with go 1.22.0. >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/af944ed8-34fe-4d28-8a0e-f786b3974e99n%40googlegroups.com.
