The same env-var is used for action/setup-go as for overriding
the default Go version in Dockerfiles, however action/setup-go
only accepts SemVer (e.g. 1.25.0-rc.1) whereas the official golang
image follows the Go project's versioning, which doesn't use
a SemVer-compatible format (go1.25rc1 / 1.25rc1).

Trying to use the same "GO_VERSION" value for both will therefore
fail.

As we're already updating the default version in the Dockerfile to
the version we want to use, let's remove the --build-arg, and use
the default that's set in the Dockerfile.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit fa4f3c9)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>

Signed-off-by: CrazyMax <1951866+crazy-max@users.noreply.github.com>
(cherry picked from commit fcf666f)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>

Signed-off-by: Niel Drummond <niel@drummond.lu>
(cherry picked from commit bfc0c7c)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>

Signed-off-by: Niel Drummond <niel@drummond.lu>
(cherry picked from commit 51d6687)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>

The hosted Windows 2019 runners reach EOL on June 30;
actions/runner-images#12045

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 6f484d0)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 9316396)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>

The TestNatNetworkICC and TestFlakyPortMappedHairpinWindows (TestPortMappedHairpinWindows)
tests were frequently failing on Windows with a context timeout;

    === FAIL: github.com/docker/docker/integration/networking TestNatNetworkICC/User_defined_nat_network (9.67s)
        nat_windows_test.go:62: assertion failed: error is not nil: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.51/containers/4357bd24c9b77b955ee961530d1f552ce099b3dcbeb396db599971b2396d8b08/start": context deadline exceeded
        panic.go:636: assertion failed: error is not nil: Error response from daemon: error while removing network: network mynat has active endpoints (name:"ctr2" id:"dc8d597dafef")

    === FAIL: github.com/docker/docker/integration/networking TestNatNetworkICC (18.34s)

    === FAIL: github.com/docker/docker/integration/networking TestFlakyPortMappedHairpinWindows (13.02s)
        nat_windows_test.go:110: assertion failed: error is not nil: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.51/containers/65207ae3d6953d85cd2123feac45af60b059842d570d4f897ea53c813cba3cb4/start": context deadline exceeded
        panic.go:636: assertion failed: error is not nil: Error response from daemon: error while removing network: network clientnet has active endpoints (name:"amazing_visvesvaraya" id:"18add58d415e")

These timeouts were set in c1ab6ed and
2df4391, and were shared between Linux
and Windows; likely Windows is slower to start, so these timeouts to be
expected.

Let's increase the context timeout to give it a bit more time.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 0ea28fe)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>

[28.x backport] dockerfile: update govulncheck to v1.1.4

[28.x backport] api: swagger: Tweak type of GwPriority to integer

[28.x backport] gha: remove GO_VERSION build-arg from builds

[28.x backport] integration/networking: increase context timeout for attach

- https://github.com/golang/go/issues?q=milestone%3AGo1.24.5+label%3ACherryPickApproved
- full diff: golang/go@go1.24.4...go1.24.5

This minor releases include 1 security fixes following the security policy:

- cmd/go: unexpected command execution in untrusted VCS repositories

    Various uses of the Go toolchain in untrusted VCS repositories can result in
    unexpected code execution. When using the Go toolchain in directories fetched
    using various VCS tools (such as directly cloning Git or Mercurial repositories)
    can cause the toolchain to execute unexpected commands, if said directory
    contains multiple VCS configuration metadata (such as a '.hg' directory in a Git
    repository). This is due to how the Go toolchain attempts to resolve which VCS
    is being used in order to embed build information in binaries and determine
    module versions.

    The toolchain will now abort attempting to resolve which VCS is being used if it
    detects multiple VCS configuration metadata in a module directory or nested VCS
    configuration metadata (such as a '.git' directoy in a parent directory and a
    '.hg' directory in a child directory). This will not prevent the toolchain from
    building modules, but will result in binaries omitting VCS related build
    information.

    If this behavior is expected by the user, the old behavior can be re-enabled by
    setting GODEBUG=allowmultiplevcs=1. This should only be done in trusted
    repositories.

    Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting
    this issue.

    This is CVE-2025-4674 and https://go.dev/issue/74380.

View the release notes for more information:
https://go.dev/doc/devel/release#go1.24.5

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit 0a047e8)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>

[28.x backport] gha: update to windows 2022 / 2025

[28.x backport] Update to go1.24.5