Created a issue based on our discussion: https://github.com/golang/go/issues/65653
On Saturday, February 10, 2024 at 10:49:58 PM UTC+1 Martin wrote: > Hey Aldemar and Thomas, > > thanks for your hints. > > > While trying to upgrade a go package to 1.22.0 today, I ran into this > same issue in my coverage step. From testing different combinations of > options for `go test`, it seems that the 'no such file or directory' errors > and resulting non-zero exit code occur when go test processes a > folder/package that isn't included in the -coverpkg list- e.g. in your > case, any package that isn't part of ./internal. When I set -coverpkg equal > to the entire list of packages in the project, the error goes away. > > You are right, if I adopt your command, the errors go away. > > There seem several issues with the new code coverage design, see > https://github.com/golang/go/issues/65570 > https://github.com/golang/go/issues/65636 > > In both issues its addressed, that with > $ GOEXPERIMENT=nocoverageredesign go test -v ./... > -coverprofile=coverage.out -coverpkg=./internal/... -covermode count > > The old behaviour is used and the error is gone as well. > > I assume the root cause is related to the both issues linked above, but > will create a new issue anyway. > I will include your findings as well. > > On Thursday, February 8, 2024 at 11:14:58 PM UTC+1 Thomas McNulty wrote: > >> While trying to upgrade a go package to 1.22.0 today, I ran into this >> same issue in my coverage step. From testing different combinations of >> options for `go test`, it seems that the 'no such file or directory' errors >> and resulting non-zero exit code occur when go test processes a >> folder/package that isn't included in the -coverpkg list- e.g. in your >> case, any package that isn't part of ./internal. When I set -coverpkg equal >> to the entire list of packages in the project, the error goes away. >> >> Running with some packages (in this case, mocks) excluded: >> >> % go version >> go version go1.22.0 darwin/arm64 >> % CVPKG=$(go list ./... | grep -v mocks | tr '\n' ',') >> % go test -coverpkg=${CVPKG} -coverprofile=coverage.out -covermode=count >> ./... >> ... (tests passing) >> github.com/<org>/<repo>/internal/mocks/a/b: open >> /var/folders/c4/kbr99g196216gsv36c94cp840000gn/T/go-build466145861/b849/covmeta.3a394ea9611306b457bfb2f5b2169adffc13123f3b07d667fd86b58eac717920: >> >> no such file or directory >> github.com/<org>/<repo>/internal/mocks/c: open >> /var/folders/c4/kbr99g196216gsv36c94cp840000gn/T/go-build466145861/b851/covmeta.5fc2c6ff11ae04da5c2cdbbb4c9e9e64d515086b2a7a7f5660d5dc409cdf5724: >> >> no such file or directory >> github.com/<org>/<repo>/internal/mocks/e/f: open >> /var/folders/c4/kbr99g196216gsv36c94cp840000gn/T/go-build466145861/b853/covmeta.2405ba52a1121a0f4a20da157347d9217eff95f8d18b9ae656cf0414aefe8221: >> >> no such file or directory >> ... (more tests passing) >> % echo $? >> >> 1 >> >> >> Vs. running with no packages excluded: >> >> % go version >> go version go1.22.0 darwin/arm64 >> % CVPKG=$(go list ./... | tr '\n' ',') >> % go test -coverpkg=${CVPKG} -coverprofile=coverage.out -covermode=count >> ./... >> .... (all tests passing) >> % echo $? >> 0 >> On Thursday, February 8, 2024 at 2:41:18 PM UTC-5 Martin Schallnahs wrote: >> >>> 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/6cf11254-ef82-4642-92ba-587dca5bbc63n%40googlegroups.com.
