$ 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/46b238c7-37c8-40ba-a3a4-ea825a1d29e4n%40googlegroups.com.

Reply via email to