[v0.17] Dependency updates

[tonistiigi]

- Containerd v1.7.22
- Runc v1.1.15
- docker/docker v27.3.1
- docker/cli v27.3.1
- OTEL 1.21.0
- grpc v1.66.2
- compose-go v2.4.1
- hcsshim v0.12.5

• some patch release bumps

[tonistiigi]

hcsshim v0.12.5 and containerd 1.7.23 are incompatible :

[tonistiigi]

    sandbox.go:138: buildkitd: plugin type="loopback" failed (add): interrupted system call
    sandbox.go:138: CNI setup error

@AkihiroSuda Any ideas?

[AkihiroSuda]

failed (add): interrupted system call

Perhaps https://github.com/containernetworking/plugins lacks an EINTR retry loop?

[crazy-max]

LGTM

• compose-go v2.4.1

This one is buildx only right?

[tonistiigi]

Reverted the CNI bump as well. Not great as this will mean that CVE scanners will mark the release for all the old Go issues. Nothing too obvious in CNI changelog.

[crazy-max]

Should we keep 1.7.22 if we can't vendor the go module?

[tonistiigi]

They don't need to be the same. We are still compatible with v1.7.23 daemon.

[thaJeztah]

hcsshim v0.12.5 and containerd 1.7.23 are incompatible :

For containerd 1.7.23 you either need to stay on 0.11 or you need to update to hcsshim v0.12.8, but that comes with a whole lot of dependency updates; see the PRs linked from this one;

• vendor: github.com/containerd/containerd v1.7.23, hcsshim v0.12.8 moby#48544

go modules won't do that update, because v0.12.x (any v0.12.x version) is higher than v0.11 (what containerd v1.7.23 uses), so it considers it high enough.

In moby we wanted to stay on v0.11 for the 27.x branch, and only updated hcsshim to v0.12 for master.

So BuildKit can decide to either revert to v0.11, and keep v0.12 for the next release (together with moby v28.0), or do all the other updates as well.