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/9cf94f01-5837-4f12-953f-7cd4c6b2e9efn%40googlegroups.com.
