[go-nuts] Arctic Warfare is now available (powered by Ebitengine)

[Trevor Slocum]

Arctic Warfare is now available to play. Battle tanks in the arctic, 
demolish trees and annihilate snowmen.

Play: https://rocketnine.itch.io/arctic-warfare
Code: https://code.rocket9labs.com/tslocum/arcticwarfare

-- 
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/4f3826b7-fc10-4cae-b970-7874565b3387n%40googlegroups.com.

Re: [go-nuts] Re: templates not working for me

[Ian Lance Taylor]

On Wed, Feb 7, 2024 at 10:11 PM joseph.p...@gmail.com
 wrote:
>
> Variable substitution doesn't seem to work in an included template file. Is 
> that a known limitation?

golang-nuts is for general discussion of Go, its tools, and its
standard library.  It's fine to ask about the Gin web framework here,
but you are likely to get better answers if you ask in a forum that is
focused on Gin.

Ian

-- 
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/CAOyqgcU1rYb8F5_WLvN9tNk9tT4DpcMmtk8_7RbyBWK3_17Tjw%40mail.gmail.com.

Re: [go-nuts] Re: Changing PWD ruins test caching

[Kevin Burke]

You're right. I ended up inserting a shim to replace os/env.go in the
standard library, that would dump the stack trace of anything that called
os.Getenv("PWD"). It turns out that a popular testing library was doing
this - https://github.com/onsi/ginkgo/issues/1355.

On Thu, Feb 8, 2024 at 3:19 PM 'Sean Liao' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Using a basic example which just imports os
> https://go.dev/play/p/BmX0ds901-4 (the rest copied from gobyexample)
> copied to 2 different directories, I do see cache hits, so I don't
> think it's from just the import?
>
> 23:12:37 ~/tmp/testrepo0530/a 0:00:00
> main » go1.22.0 test .
> testcache: example: test ID 7554777255756c714a6773663261576871416373
> => d9016fd4db0cc529026c3bdf959d21e8b37da70f61b3b9bd14cebcf4bcc41e0c
> testcache: example: input list not found: cache entry not found: open
>
> /home/user/.cache/go-build/d9/d9016fd4db0cc529026c3bdf959d21e8b37da70f61b3b9bd14cebcf4bcc41e0c-a:
> no such file or directory
> testcache: example: test ID 695f4e6944335a64497850503861366643364c48
> => e7d8d7272b091d2d5d155ff077e599c1e7c31eaad2d9bf3549e2d03149e94357
> testcache: example: input list not found: cache entry not found: open
>
> /home/user/.cache/go-build/e7/e7d8d7272b091d2d5d155ff077e599c1e7c31eaad2d9bf3549e2d03149e94357-a:
> no such file or directory
> testcache: example: save test ID
> d9016fd4db0cc529026c3bdf959d21e8b37da70f61b3b9bd14cebcf4bcc41e0c =>
> input ID 8671bffc7a3ec5201bb26a0eccecb5599259f0d0e63624375378b61cc00a0733
> => 516ef3f5e0d83ea893583f43f60e654775b3769b5f99f2de7b99487eae637298
> testcache: example: save test ID
> e7d8d7272b091d2d5d155ff077e599c1e7c31eaad2d9bf3549e2d03149e94357 =>
> input ID 8671bffc7a3ec5201bb26a0eccecb5599259f0d0e63624375378b61cc00a0733
> => 42e8604e2c4807cd097efad167887d4d0ddfc76afda71e21f8145604d93ebce5
> ok  example 0.001s
>
> 23:12:42 ~/tmp/testrepo0530/a 0:00:00
> main » cd ../b
>
> 23:12:46 ~/tmp/testrepo0530/b 0:00:00
> main » go1.22.0 test .
> testcache: example: test ID 7554777255756c714a6773663261576871416373
> => d9016fd4db0cc529026c3bdf959d21e8b37da70f61b3b9bd14cebcf4bcc41e0c
> testcache: example: test ID
> d9016fd4db0cc529026c3bdf959d21e8b37da70f61b3b9bd14cebcf4bcc41e0c =>
> input ID 8671bffc7a3ec5201bb26a0eccecb5599259f0d0e63624375378b61cc00a0733
> => 516ef3f5e0d83ea893583f43f60e654775b3769b5f99f2de7b99487eae637298
> ok  example (cached)
>
>
> - sean
>
> On Thu, Feb 8, 2024 at 12:13 AM Kevin Burke  wrote:
> >
> > Sorry for slow reply. We are using Alpine, which I don't think is either
> of those flavors.
> >
> > I discovered this by enabling GODEBUG=gocachehash=1, running the tests
> twice, and then checking the diff between the two test runs.
> >
> > On Tue, Nov 28, 2023 at 11:57 AM 'Bryan C. Mills' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
> >>
> >> As far as I can tell the code in question is only built on AIX and
> OpenBSD — are you using one of those two platforms?
> >> If not, perhaps the caching problem is coming from somewhere else.
> >>
> >> That said, it does appear that calls to `os.Chdir` result in a spurious
> dependency on the PWD variable:
> >>
> https://cs.opensource.google/go/go/+/master:src/os/file.go;l=340-345;drc=d961b12be9001cf8dbf8f52847607dbf84d94f8d
> >>
> >> On Thursday, November 23, 2023 at 1:50:04 PM UTC-5 Kevin Burke wrote:
> >>>
> >>> We have some tests that are pretty slow. I would like to use Go's test
> caching to skip them in our CI environment, if nothing in the code or the
> environment has changed. Our CI environment has a set of _agents_, each of
> which can run multiple jobs simultaneously. As a result, they check out
> code into a different directory each time they run a job.
> >>>
> >>> Go's test caching checks every env var loaded by the test program. If
> any of them change, then Go assumes that the cache is busted and the test
> must be run.
> >>>
> >>> Any program that imports "os" hits this logic in the os package, which
> checks the value of the $PWD environment variable:
> >>>
> >>> // We query the working directory at init, to use it later to search
> for the
> >>> // executable file
> >>> // errWd will be checked later, if we need to use initWd
> >>> var initWd, errWd = Getwd()
> >>>
> >>> So checking code out to different directories means that any program
> that imports "os" cannot have test caching. This seems like a shame because
> the code is all laid out in the same place in the working directory.
> >>>
> >>> Has anyone tried to fix this issue? Do you think this is worth trying
> to patch or modify the test caching behavior in Go itself? I could solve
> this by running a chroot or another layer of Docker, of course, but I'd
> prefer not to do these because of the difficulty of getting data in and out
> of each one, communicating with other Docker containers, etc.
> >>
> >> --
> >> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> >> To unsubscribe from this 

Re: [go-nuts] Re: 1.22.0 ServeMux HandleFunc infinite loop

['Sean Liao' via golang-nuts]

I've filed it as https://go.dev/issue/65624

- sean

On Thu, Feb 8, 2024 at 6:58 PM Kyle Shannon  wrote:
>
> On 2/8/24 11:30, Jason Phillips wrote:
>
> Can you create a small self-contained program that reproduces the issue? The 
> following program returns 404 locally, as I'd expect, but does get killed in 
> the Go playground: https://go.dev/play/p/FigBLK8KrAK
>
> Perhaps a simpler reproduction that's runnable on the playground:
>
> https://go.dev/play/p/gmQGJsyNCT6
>
> This returns 301 with a Location of /x/.  Note the trailing slash in the mux 
> pattern, which was missing in your example.
>
>
> Perhaps there's an issue with the Playground networking implementation that's 
> incompatible with the 1.22 changes?
>
> On Thursday, February 8, 2024 at 12:03:46 PM UTC-5 Patricia Decker wrote:
>>
>> I haven't played around with it yet, but have you tried to separately 
>> register /something/ ?
>>
>> mux := http.NewServeMux()
>> mux.HandleFunc("/something/", func...)
>> mux.HandleFunc("/something/{id}/{$}", func...)
>>
>> On Wednesday, February 7, 2024 at 1:21:00 PM UTC-8 Péter Szarvas wrote:
>>>
>>> Hello,
>>>
>>> I noticed if you set up a route like /something/{id}/{$}, it results in an 
>>> infinite loop if I navigate to /someting/ (with the trailing slash). I got 
>>> a redirect to Location: /something/, and so on. Finally the page breaks 
>>> after multiple rounds.
>>>
>>> Example:
>>> mux := http.NewServeMux()
>>> mux.HandleFunc("/something/{id}/{$}", func...))
>>>
>>> Should I raise and issue or am I doing something wrong here?
>>>
>>> Thanks,
>>> Peter
>
> --
> 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/445d31e9-e9ce-407a-985c-ad448da9f786n%40googlegroups.com.
>
>
> --
> Kyle
>
> --
> 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/85cdc8ae-66cb-45e0-8ba5-b0380cee9df1%40pobox.com.

-- 
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/CAGabyPryHf98e_OcB1ffC2ZdTQ_s88Vm-kG%2Bm1mtbNu1TCAwbA%40mail.gmail.com.

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Thomas McNulty]

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///internal/mocks/a/b: open 
/var/folders/c4/kbr99g196216gsv36c94cp84gn/T/go-build466145861/b849/covmeta.3a394ea9611306b457bfb2f5b2169adffc13123f3b07d667fd86b58eac717920:
 
no such file or directory
github.com///internal/mocks/c: open 
/var/folders/c4/kbr99g196216gsv36c94cp84gn/T/go-build466145861/b851/covmeta.5fc2c6ff11ae04da5c2cdbbb4c9e9e64d515086b2a7a7f5660d5dc409cdf5724:
 
no such file or directory
github.com///internal/mocks/e/f: open 
/var/folders/c4/kbr99g196216gsv36c94cp84gn/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_wmhcgn/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 

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Aldemar F]

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_wmhcgn/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
>>> 

[go-nuts] User-visible regression in the x509.Certificate struct from go 1.21.6 to 1.22.0

[Victor Lowther]

It looks like adding the x509.OID type and associated fields to the 
x509.Certificate struct breaks the ability to gob-encode the certificate.  
The following test program succeeds on go 1.21.6 and fails on 1.22.0:

package main

import (
"log"
"bytes"
"encoding/gob"
"crypto/x509"
"crypto/rsa"
"crypto/dsa"
"crypto/ecdh"
"crypto/ecdsa"
"crypto/ed25519"
)

func init() {
gob.Register(rsa.PrivateKey{})
gob.Register(dsa.PrivateKey{})
gob.Register(ecdh.PrivateKey{})
gob.Register(ecdsa.PrivateKey{})
gob.Register(ed25519.PrivateKey{})
gob.Register(rsa.PublicKey{})
gob.Register(dsa.PublicKey{})
gob.Register(ecdh.PublicKey{})
gob.Register(ecdsa.PublicKey{})
gob.Register(ed25519.PublicKey{})
}

func main() {
c := {}
b := {}

enc := gob.NewEncoder(b)
if err := enc.Encode(c); err != nil {
log.Printf("Failed to gob encode empty x.509 cert: %v", err)
} else {
log.Printf("Encoded empty x.509 cert")
}
}

It looks like the x509.OID type is not able to be marshalled by gob since 
it is a struct that contains a single unexported field, and it doesn't 
implement text or binary marshalling.

-- 
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/2a335349-3c9b-45b5-94d5-fb4f8c7edabcn%40googlegroups.com.

Re: [go-nuts] Re: 1.22.0 ServeMux HandleFunc infinite loop

[Patricia Decker]

Thanks for that! Adding the additional HandleFunc for "/x/" does result in
a 200: https://go.dev/play/p/5upNoAhAlPs

On Thu, Feb 8, 2024 at 10:59 AM Kyle Shannon  wrote:

> On 2/8/24 11:30, Jason Phillips wrote:
>
> Can you create a small self-contained program that reproduces the issue?
> The following program returns 404 locally, as I'd expect, but does get
> killed in the Go playground: https://go.dev/play/p/FigBLK8KrAK
>
> Perhaps a simpler reproduction that's runnable on the playground:
>
> https://go.dev/play/p/gmQGJsyNCT6
>
> This returns 301 with a Location of /x/.  Note the trailing slash in the
> mux pattern, which was missing in your example.
>
>
> Perhaps there's an issue with the Playground networking implementation
> that's incompatible with the 1.22 changes?
>
> On Thursday, February 8, 2024 at 12:03:46 PM UTC-5 Patricia Decker wrote:
>
>> I haven't played around with it yet, but have you tried to separately
>> register /something/ ?
>>
>> mux := http.NewServeMux()
>> mux.HandleFunc("/something/", func...)
>> mux.HandleFunc("/something/{id}/{$}", func...)
>>
>> On Wednesday, February 7, 2024 at 1:21:00 PM UTC-8 Péter Szarvas wrote:
>>
>>> Hello,
>>>
>>> I noticed if you set up a route like /something/{id}/{$}, it results in
>>> an infinite loop if I navigate to /someting/ (with the trailing slash). I
>>> got a redirect to Location: /something/, and so on. Finally the page breaks
>>> after multiple rounds.
>>>
>>> Example:
>>> mux := http.NewServeMux()
>>> mux.HandleFunc("/something/{id}/{$}", func...))
>>>
>>> Should I raise and issue or am I doing something wrong here?
>>>
>>> Thanks,
>>> Peter
>>>
>> --
> 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/445d31e9-e9ce-407a-985c-ad448da9f786n%40googlegroups.com
> 
> .
>
>
> --
> Kyle
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/vbmvPMVhhjk/unsubscribe.
> To unsubscribe from this group and all its topics, 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/85cdc8ae-66cb-45e0-8ba5-b0380cee9df1%40pobox.com
> 
> .
>

-- 
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/CADeDRJJrdd%2BvuVOiqG1vy-FK0GW24GqxEmsioYxnUonKQPqupw%40mail.gmail.com.

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Martin Schallnahs]

P.S.: According to the release notes of golang 1.22.0 the "go test -cover" 
was worked on, so thats why insist to find out if its a bug (and also 
because it prevents me from upgrading a project to golang 1.22.0 right now).

" go test -cover now prints coverage summaries for covered packages that do 
not have their own test files. Prior to Go 1.22 a go test -cover run for 
such a package would report"

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 
>>> .
>>>
>>> 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 
>>> .
>>>
>>> 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).

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Martin Schallnahs]

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_wmhcgn/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 

Re: [go-nuts] Re: 1.22.0 ServeMux HandleFunc infinite loop

[Kyle Shannon]

On 2/8/24 11:30, Jason Phillips wrote:
Can you create a small self-contained program that reproduces the 
issue? The following program returns 404 locally, as I'd expect, but 
does get killed in the Go playground: https://go.dev/play/p/FigBLK8KrAK

Perhaps a simpler reproduction that's runnable on the playground:

https://go.dev/play/p/gmQGJsyNCT6

This returns 301 with a Location of /x/.  Note the trailing slash in the 
mux pattern, which was missing in your example.


Perhaps there's an issue with the Playground networking implementation 
that's incompatible with the 1.22 changes?


On Thursday, February 8, 2024 at 12:03:46 PM UTC-5 Patricia Decker wrote:

I haven't played around with it yet, but have you tried to
separately register /something/ ?

mux := http.NewServeMux()
mux.HandleFunc("/something/", func...)
mux.HandleFunc("/something/{id}/{$}", func...)

On Wednesday, February 7, 2024 at 1:21:00 PM UTC-8 Péter Szarvas
wrote:

Hello,

I noticed if you set up a route like /something/{id}/{$}, it
results in an infinite loop if I navigate to /someting/ (with
the trailing slash). I got a redirect to Location:
/something/, and so on. Finally the page breaks after multiple
rounds.

Example:
mux := http.NewServeMux()
mux.HandleFunc("/something/{id}/{$}", func...))

Should I raise and issue or am I doing something wrong here?

Thanks,
Peter

--
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/445d31e9-e9ce-407a-985c-ad448da9f786n%40googlegroups.com 
.


--
Kyle

--
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/85cdc8ae-66cb-45e0-8ba5-b0380cee9df1%40pobox.com.

[go-nuts] Re: 1.22.0 ServeMux HandleFunc infinite loop

[Jason Phillips]

Can you create a small self-contained program that reproduces the issue? 
The following program returns 404 locally, as I'd expect, but does get 
killed in the Go playground: https://go.dev/play/p/FigBLK8KrAK

Perhaps there's an issue with the Playground networking implementation 
that's incompatible with the 1.22 changes?

On Thursday, February 8, 2024 at 12:03:46 PM UTC-5 Patricia Decker wrote:

> I haven't played around with it yet, but have you tried to separately 
> register /something/ ?
>
> mux := http.NewServeMux()
> mux.HandleFunc("/something/", func...)
> mux.HandleFunc("/something/{id}/{$}", func...)
>
> On Wednesday, February 7, 2024 at 1:21:00 PM UTC-8 Péter Szarvas wrote:
>
>> Hello,
>>
>> I noticed if you set up a route like /something/{id}/{$}, it results in 
>> an infinite loop if I navigate to /someting/ (with the trailing slash). I 
>> got a redirect to Location: /something/, and so on. Finally the page breaks 
>> after multiple rounds.
>>
>> Example:
>> mux := http.NewServeMux()
>> mux.HandleFunc("/something/{id}/{$}", func...))
>>
>> Should I raise and issue or am I doing something wrong here?
>>
>> Thanks,
>> Peter
>>
>

-- 
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/445d31e9-e9ce-407a-985c-ad448da9f786n%40googlegroups.com.

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

['Brian Candler' via golang-nuts]

$ 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 
>> .
>>
>> 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 
>> .
>>
>> 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 

[go-nuts] Re: 1.22.0 ServeMux HandleFunc infinite loop

[Patricia Decker]

I haven't played around with it yet, but have you tried to separately 
register /something/ ?

mux := http.NewServeMux()
mux.HandleFunc("/something/", func...)
mux.HandleFunc("/something/{id}/{$}", func...)

On Wednesday, February 7, 2024 at 1:21:00 PM UTC-8 Péter Szarvas wrote:

> Hello,
>
> I noticed if you set up a route like /something/{id}/{$}, it results in an 
> infinite loop if I navigate to /someting/ (with the trailing slash). I got 
> a redirect to Location: /something/, and so on. Finally the page breaks 
> after multiple rounds.
>
> Example:
> mux := http.NewServeMux()
> mux.HandleFunc("/something/{id}/{$}", func...))
>
> Should I raise and issue or am I doing something wrong here?
>
> Thanks,
> Peter
>

-- 
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/c4389c9a-6d46-4931-9ace-c4e77b67b00bn%40googlegroups.com.

[go-nuts] Re: How to determine system requirements for an application?

[Joao Silva]

Hi friend, did you manage to solve it, I was having the same problem as you.

Em sexta-feira, 3 de julho de 2020 às 06:59:04 UTC-3, smartaq...@gmail.com 
escreveu:

> Hello,
>
> If we make an application in golang then how to determine the system 
> requirements required for its flawless execution. 
>
> What are the parameters to justify the estimated values ​​of CPU and RAM, 
> especially for the application.exe built in Golang
>
> Thanks 
>

-- 
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/d0c12bad-fd2b-49ed-bc2b-8d78d3646479n%40googlegroups.com.

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

[Martin Schallnahs]

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 
> .
>
> 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 
> .
>
> 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 

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

['Brian Candler' via golang-nuts]

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 
.

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 
.

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/9247783b-ea6f-43ed-9ba5-9384dd7e4e08n%40googlegroups.com.

[go-nuts] Re: Go 1.22.0: Alpine: go test with coverage works but returns exit status 1

['Brian Candler' via golang-nuts]

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/9c635e17-c1a4-46d0-92a1-d553e1b503f4n%40googlegroups.com.