build(deps): bump github.com/docker/docker from 25.0.0-beta.1+incompatible to 25.0.0-beta.2+incompatible

[dependabot]

Bumps github.com/docker/docker from 25.0.0-beta.1+incompatible to 25.0.0-beta.2+incompatible.

Release notes

Sourced from github.com/docker/docker's releases.

v25.0.0-beta.2

25.0.0-beta.2

This is a pre-release of the upcoming 25.0.0 release.

Pre-releases are intended for testing new releases: only install in a test environment!

curl -fsSL https://get.docker.com -o get-docker.sh
sudo CHANNEL=test sh get-docker.sh

Known issues:

• There is no changelog yet; an overview of pull requests included in this release can be found on GitHub:
  • docker cli: all pull requests for 25.0.0 / all "changelog" pull requests for 25.0.0
  • docker engine: all pull requests for 25.0.0 / all "changelog" pull requests for 25.0.0
• dockerd now uses systemd's default LimitNOFILE which on older versions of systemd, such as used by CentOS 7 is very low and may limit the number of containers that can be run. Set LimitNOFILE=1048576 to get the previous behavior.
• There are no packages available yet for the s390x and ppc64le architectures
• There may be bugs! ⚠️

Bugs and regressions can be reported in these issue trackers:

• Related to the CLI: https://github.com/docker/cli/issues
• Related to the Docker Engine https://github.com/moby/moby/issues

When reporting issues, include [25.0.0-beta] in the issue title

Commits

• 92884c2 Merge pull request #46924 from thaJeztah/vendor_singleflight
• dbdfc71 vendor: resenje.org/singleflight v0.4.1
• e8c72ad Merge pull request #46830 from thaJeztah/vendor_containerd_1.7.9
• 4d2a324 update to go.opentelemetry.io/otel/semconv/v1.21.0, remove "httpconv" uses
• 7d991b6 vendor: github.com/moby/buildkit v0.12.5-0.20231208203051-3b6880d2a00f
• fcf03cd vendor: github.com/containerd/containerd v1.7.11
• 7028a03 vendor: github.com/containerd/containerd v1.7.10
• 49ad102 vendor: github.com/containerd/containerd v1.7.9
• c14bd4f vendor: vendor: upgrade OpenTelemetry to v1.19.0 / v0.45.0
• 65973c6 Merge pull request #46923 from thaJeztah/update_securejoin
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[thaJeztah]

OTEL Strikes again;

#18 2.021 go: github.com/docker/compose/v2/internal/tracing imports
#18 2.021 	go.opentelemetry.io/otel/exporters/otlp/otlptrace imports
#18 2.021 	go.opentelemetry.io/otel/exporters/otlp/internal: module go.opentelemetry.io/otel/exporters/otlp@latest found (v0.20.1), but does not contain package go.opentelemetry.io/otel/exporters/otlp/internal
#18 2.021 go: github.com/docker/compose/v2/internal/tracing imports
#18 2.021 	go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc imports
#18 2.021 	go.opentelemetry.io/otel/exporters/otlp/otlptrace/internal/otlpconfig imports
#18 2.021 	go.opentelemetry.io/otel/exporters/otlp/internal/envconfig: module go.opentelemetry.io/otel/exporters/otlp@latest found (v0.20.1), but does not contain package go.opentelemetry.io/otel/exporters/otlp/internal/envconfig
#18 2.021 go: github.com/docker/compose/v2/pkg/api imports
#18 2.021 	github.com/docker/docker/client imports
#18 2.021 	go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp imports
#18 2.021 	go.opentelemetry.io/otel/metric/global: module go.opentelemetry.io/otel/metric@latest found (v1.21.0), but does not contain package go.opentelemetry.io/otel/metric/global
#18 2.021 go: github.com/docker/compose/v2/pkg/api imports
#18 2.021 	github.com/docker/docker/client imports
#18 2.021 	go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp imports
#18 2.021 	go.opentelemetry.io/otel/metric/instrument: module go.opentelemetry.io/otel/metric@latest found (v1.21.0), but does not contain package go.opentelemetry.io/otel/metric/instrument

As docker/docker does not use a go.mod, this may need manual intervention to specify the right versions (probably including "containerd") see:

• vendor: OTEL v1.19.0 / v0.45.0, containerd v1.7.11 moby/moby#46830
• vendor: github.com/docker/docker 92884c25b394 (v25.0.0-dev) cli#4704

/cc @milas @ndeloof

[ndeloof]

there's also an issue with mockgen to require a go.mod in dependencies (IIUC)

mockgen -destination pkg/mocks/mock_docker_cli.go -package mocks github.com/docker/cli/cli/command Cli
# github.com/docker/cli/cli/context/store
../../../../../pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/storeconfig.go:6:24: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
...
prog.go:14:2: no required module provides package github.com/docker/cli/cli/command: go.mod file not found in current directory or any parent directory; see 'go help modules'

otherwise it assumes go 1.16 and reject use of any

[thaJeztah]

Interesting; trying to find where it gets the 1.16 from. There's 2 go.mod files in man and docs/generate but those make those directories separate modules, so not part of the docker CLI itself.

There are some (indirect) dependencies that use go1.16, but not sure how that would affect things here.

git grep 1\\.16 -- ':(exclude)*.md' ':(exclude)*.svg' ':(exclude)*.yml'
docs/generate/go.mod:go 1.16
e2e/global/cli_test.go:// Prior to go1.16, https:// schemes would use HTTPS_PROXY, and any other
man/go.mod:go 1.16
vendor/github.com/go-logr/stdr/stdr.go:         // Go's log.Default() is only available in 1.16 and higher.
vendor/github.com/klauspost/compress/s2sx.mod:go 1.16
vendor/golang.org/x/net/idna/tables12.0.0.go://go:build go1.14 && !go1.16
vendor/golang.org/x/net/idna/tables12.0.0.go:// +build go1.14,!go1.16
vendor/golang.org/x/net/idna/tables13.0.0.go://go:build go1.16 && !go1.21
vendor/golang.org/x/net/idna/tables13.0.0.go:// +build go1.16,!go1.21
vendor/golang.org/x/net/idna/trie12.0.0.go://go:build !go1.16
vendor/golang.org/x/net/idna/trie12.0.0.go:// +build !go1.16
vendor/golang.org/x/net/idna/trie13.0.0.go://go:build go1.16
vendor/golang.org/x/net/idna/trie13.0.0.go:// +build go1.16
vendor/golang.org/x/text/unicode/bidi/tables12.0.0.go://go:build go1.14 && !go1.16
vendor/golang.org/x/text/unicode/bidi/tables12.0.0.go:// +build go1.14,!go1.16
vendor/golang.org/x/text/unicode/bidi/tables13.0.0.go://go:build go1.16 && !go1.21
vendor/golang.org/x/text/unicode/bidi/tables13.0.0.go:// +build go1.16,!go1.21
vendor/golang.org/x/text/unicode/norm/tables12.0.0.go://go:build go1.14 && !go1.16
vendor/golang.org/x/text/unicode/norm/tables12.0.0.go:// +build go1.14,!go1.16
vendor/golang.org/x/text/unicode/norm/tables13.0.0.go://go:build go1.16 && !go1.21
vendor/golang.org/x/text/unicode/norm/tables13.0.0.go:// +build go1.16,!go1.21
vendor/golang.org/x/text/width/tables12.0.0.go://go:build go1.14 && !go1.16
vendor/golang.org/x/text/width/tables12.0.0.go:// +build go1.14,!go1.16
vendor/golang.org/x/text/width/tables13.0.0.go://go:build go1.16 && !go1.21
vendor/golang.org/x/text/width/tables13.0.0.go:// +build go1.16,!go1.21
vendor/golang.org/x/tools/go/packages/golist.go:        // below 1.16. Otherwise, go list handles it.
vendor/golang.org/x/tools/go/packages/golist.go:        // For Go versions 1.16 and above, `go list` accepts overlays directly via
vendor/golang.org/x/tools/go/packages/packages.go:      // Should we assert a hard minimum of (currently) go1.16 here?
vendor/golang.org/x/tools/go/packages/packages.go:var _ interface{} = io.Discard // assert build toolchain is go1.16 or later
vendor/golang.org/x/tools/internal/tokeninternal/tokeninternal.go:              // This type remained essentially consistent from go1.16 to go1.21.
vendor/golang.org/x/tools/internal/typesinternal/types.go:// generated by Go version 1.16 and later: the error code, start position, and
vendor/modules.txt:## explicit; go 1.16
vendor/modules.txt:## explicit; go 1.16
vendor/modules.txt:## explicit; go 1.16
vendor/modules.txt:## explicit; go 1.16
vendor/modules.txt:## explicit; go 1.16
vendor/modules.txt:## explicit; go 1.16

[ndeloof]

Tried a hack using a local working copy to generate mocks, still can't get CI to run as golangci-lint has the same issue:

#21 83.25 internal/tracing/docker_context.go:26:2: could not import github.com/docker/cli/cli/context/store (-: # github.com/docker/cli/cli/context/store
#21 83.25 /go/pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/storeconfig.go:6:24: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
#21 83.25 /go/pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/store.go:74:12: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
#21 83.25 /go/pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/store.go:75:23: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
#21 83.25 /go/pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/metadatastore.go:43:58: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
#21 83.25 /go/pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/metadatastore.go:48:22: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
#21 83.25 /go/pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/metadatastore.go:80:30: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)) (typecheck)
#21 83.25 	"github.com/docker/cli/cli/context/store"

[ndeloof]

I'm sorry to conclude docker/cli would be unusable by third-party projects since it adopted go 1.18 generic types, until it also adopt go modules 😰

[ndeloof]

Seems this is caused by https://github.com/golang/go/blob/58c28ba286dd0e98fe4cca80f5d64bbcb824a685/src/cmd/go/internal/gover/version.go#L15-L24

[ndeloof]

(hope this is just about docker/cli@0e73168 and this doesn't have more impacts)

[thaJeztah]

Could it be mockgen which is deprecated / archived? https://github.com/golang/mock

Looks like that has a go.mod with go1.15, and it was archived around go1.16 https://github.com/golang/mock/blob/main/go.mod

[thaJeztah]

Doh! Didn't see your comment (browser cache);

Seems this is caused by https://github.com/golang/go/blob/58c28ba286dd0e98fe4cca80f5d64bbcb824a685/src/cmd/go/internal/gover/version.go#L15-L24

[thaJeztah]

Capturing a Slack conversation from the maintainers channel with Cory;

A module with a go.mod without a go line is assumed to be go 1.16. A go.work file without a go line is assumed to be go 1.18.
It’s weird that imported modules without a go.mod are assumed to have language version go 1.16. I wonder if go get is generating a stub go.mod locally or something?
..
Yes, go get does synthesize go.mod files. (https://go.dev/ref/mod#non-module-compat:~:text=If%20the%20module%E2%80%99s%20path%20is%20equal%20to%20the%20repository%20root%20path%2C%20and%20the%20repository%20root%20directory%20does%20not%20contain%20a%20go.mod%20file%2C%20the%20go%20command%20synthesizes%20a%20go.mod%20file%20in%20the%20module%20cache%20that%20contains%20a%20module%20directive%20and%20nothing%20else.

If the module's path is equal to the repository root path, and the repository root directory does not contain a go.mod file, the go command synthesizes a go.mod file in the module cache that contains a module directive and nothing else.
...
golang/go#60915 is also very relevant. The root of the issue (in the opinion of the Go maintainers) is that we are trying to build non-module packages in module-aware mode

So (my interpretation):

• In "go modules" mode; if there's no go.mod, Go generates one, but it's an empty go.mod, and therefore it falls back to go 1.16, which downgrades the language-version (and any language feature > 1.16 is not supported)
• In vendor mode, that doesn't happen, and it just uses the language version of the Go version used (1.21 in this case)

Cory also found that there's an escape-hatch;

https://go.dev/doc/toolchain#:~:text=The%20go%20line%20for,file%20to%20Go%201.22.

The go line for each module sets the language version the compiler enforces when compiling packages in that module. The language version can be changed on a per-file basis by using a build constraint.

For example, a module containing code that uses the Go 1.21 language version should have a go.mod file with a go line such as go 1.21 or go 1.21.3. If a specific source file should be compiled only when using a newer Go toolchain, adding //go:build go1.22 to that source file both ensures that only Go 1.22 and newer toolchains will compile the file and also changes the language version in that file to Go 1.22.

So adding //go:build go1.22 means switching Go language version on a per file base 🤯

⚠️ but it may also mean: downgrading Go versions on those files; which is not problematic as long as you're not editing the file and want to add new code (which may now cause errors that the feature is not available).

I was curious WHY DOWNGRADE? Because the Go 1.0 compatibility promise should guarantee compatibility; new versions may add new functionality, but those changes should always be "additive"; any existing feature should continue to work! So when building with go1.21, why not build with that language version?

(The reverse I understand; if the main module would use go1.16 and a dependency declares go1.18 it could produce an error (must use newer tool chain))

And the reason for that seems to be https://go.googlesource.com/proposal/+/master/design/56986-godebug.md

Which, if I understand correctly, describes (again, my interpretation);

• "we have go1.0 compatibility promise"
• but on various occasions we decided to break compatibility
• and instead added a GODEBUG option to un-break backward compatibility
• which now has to be known by users, so can now be set as //go:debug lines

(And to do those fixes automatically .. downgrading language versions will set implicit //go:debug lines to match behavior of older versions?)

I'm curious how that works though; wondering if things like Windows switching "resolver" will now disable netgo for some files and enable it for other files? moby/moby#45603

[thaJeztah]

Concluding;

1. as with anything Go: it's not breaking the "go1.0 compatibility promise" (you're just holding it wrong)
2. if it is: see 1.
3. moving to go modules would "fix" all of this; for the docker/cli we should be mostly ready to make the switch (since remove buildkit as dependency from the CLI (integrate github.com/moby/buildkit/util/appcontext) cli#4457)
4. BUT there's a non-insignificant risk, so we may not want to do that for v25.0 (see switch to go module cli#4116 (comment))
5. For moby/moby there's a lot more things to resolve before we can switch to go modules (see the complex dependency tree above), but it MAY have similar issues already (due to use of generics in some packages) ⚠️

To fix:

• For the CLI, I want to do a quick try to see if adding the //go:build tags work, but (honestly) those may be a bit of a maintenance nightmare.
• Alternatively, revert docker/cli@0e73168 (part of golangci-lint: enable more linters cli#3770)
• ⚠️ but there may be other packages/files that are hiding similar issues (but not imported in compose, thus not triggering the issue ❓)
• ⚠️ and moby/moby MAY have more as well
• ❓ And because these errors don't trigger in "non-module" mode, may not even be possible to verify ⚠️ (maybe with some go list or other magic things to get metadata?)

[dependabot]

Looks like github.com/docker/docker is up-to-date now, so this is no longer needed.