sync: update CI config files

[web3-bot]

Syncing to commit protocol/.github@2821662.

[galargh]

@mvdan it looks like here the addition of -coverpkg=./... results in the following error:

panic: /tmp/go-build479579212/b001/zeroconf.test flag redefined: name

Do you know why that might be? I've been able to reproduce this locally as well.

[mvdan]

Here are the flags defined twice, but not really:

$ git grep '"name"'
examples/proxyservice/server.go:    name     = flag.String("name", "GoZeroconfGo", "The name for the service.")
examples/register/server.go:    name     = flag.String("name", "GoZeroconfGo", "The name for the service.")

This is not really a bug in our code, nor our fault, but it's still what is triggering the error. The umbrella issue upstream is golang/go#23910.

The short version is that, to capture coverage for all packages with -coverpkg=./..., go test forces each package's test binary to import and link all packages in ./.... Building both of those example packages into the same main package means that both init funcs try to register the name flag, hence the error.

The right fix is to fix that bug upstream, because it shouldn't be adding imports which aren't necessary.

I had forgotten about that bug, though. Without a fix, -coverpkg=./... is just a bit unreliable.

I'll take a closer look at this when I have more time. I think we might be able to use a bit of scripting to work around the bug.

[mvdan]

How about this monstrosity?

go test -coverpkg=$(go list -json ./... | jq -rs '[.[] | select(.Name != "main") | .ImportPath] | join(",")') ./...

Essentially, -coverpkg=./... makes all packages count towards each package being tested. The problem arises with main packages, whose init funcs may collide with declared flags or other global state that may need to be unique.

The go list and jq command above filters the main packages out of ./..., and prints the output in the format that -coverpkg wants - a comma-separated list. It should work.

There's one major caveat, though - if we're testing a main package, then it won't count towards its own coverage. -coverpkg replaces the default of "current package being tested", it's not in addition to the current package. So it feels like a step backwards from not supplying -coverpkg at all.

I think we should call it quits with -coverpkg. When I added the flag, I forgot about this bug with main packages. I do think the upstream bug will be fixed, but it may be one or two releases until that happens. cc @marten-seemann

[marten-seemann]

I think we should call it quits with -coverpkg. When I added the flag, I forgot about this bug with main packages. I do think the upstream bug will be fixed, but it may be one or two releases until that happens. cc @marten-seemann

I'm fine with dropping this, but let's not do another deployment run for this. It looks like zeroconf is the only package that's affected, and we can live with the slightly outdated CI config for another 2 months.

[galargh]

I'm fine with dropping this, but let's not do another deployment run for this. It looks like zeroconf is the only package that's affected, and we can live with the slightly outdated CI config for another 2 months.

I can confirm that I haven't seen a similar looking error in any other repository.