Revert "vendor: docker, docker/cli v28.0.0-rc.1"

[crazy-max]

reverts #5602 (only docker 28.0.0-rc.1, we keep XFT deps)

Forgot that we need a stable moby release before releasing 🙈

[thaJeztah]

Why the revert?

[crazy-max]

• Revert "vendor: golang.org/x/sys v0.29.0"
  914a96a
• Revert "vendor: google.golang.org/genproto/googleapis/api 324edc3d5d38"
  b0ed24a
• Revert "vendor: github.com/vishvananda/netns v0.0.5"
  e1d0bae
• Revert "vendor: github.com/moby/term v0.5.2"
  0fceead
• Revert "vendor: github.com/containerd/cgroups/v3 v3.0.5"

@thaJeztah If these deps are necessary for XFT depedencies let us know

[tonistiigi]

Revert is because there will not be a Moby GA release before BuildKit GA. We can bring this back to master after the release branch has been cut.

This is specific to moby & cli. For any XFT dependencies, we can update if needed.

[vvoland]

Revert is because there will not be a Moby GA release before BuildKit GA.

What are the technical reasons for needing a tagged GA release?

RCs are as close to GA as you can get. All changes that could potentially be breaking are already there. The only reason for vendoring RCs is to get around the circular dependency issue.

Ideally, the git reference for the GA and last RC should be the same - that's what we do with vendoring moby in docker/cli:

• vendor: github.com/docker/docker 6c3797923dcb (master, v28.0-dev) docker/cli#5754
• vendor: github.com/docker/docker/v28.0.0-rc.1 docker/cli#5805

[crazy-max]

The only reason for vendoring RCs is to get around the circular dependency issue.

We were consistent with past BuildKit releases vendoring latest Moby stable:

• https://github.com/moby/buildkit/blob/v0.19.0-rc1/go.mod#L34-L35
• https://github.com/moby/buildkit/blob/v0.17.0-rc1/go.mod#L34-L35
• https://github.com/moby/buildkit/blob/v0.16.0-rc1/go.mod#L34-L35
• https://github.com/moby/buildkit/blob/v0.15.0-rc1/go.mod#L34-L35
• https://github.com/moby/buildkit/blob/v0.14.0-rc1/go.mod#L31-L32
• ...

And don't recall we got issues with dependencies as we align them across projects before cutting a release.

RCs are as close to GA as you can get.

If that's the case I think that's fine but doesn't look like it for some of them:

• moby/moby@v27.4.0-rc.1...v27.4.0-rc.3
• moby/moby@v27.0.0-rc.1...v27.0.0-rc.2
• moby/moby@v26.0.0-rc1...v26.0.0-rc3

[vvoland]

There are breaking changes in v28 client interface, which AFAIK will make it unable for the compose to vendor buildx 0.21.

[thaJeztah]

If that's the case I think that's fine but doesn't look like it for some of them:

For the larger diffs in those, you know those were because we had to update dependencies to get to the latest BuildKit?

And I think for all of those, there had been long-lived draft PRs to verify status long before merged. Whereas the reverse usually is not the case.

[crazy-max]

There are breaking changes in v28 client interface, which AFAIK will make it unable for the compose to vendor buildx 0.21.

Oh compose requires docker 28? Then yes that would mean we need docker 28 vendored in Buildx.

[tonistiigi]

There are breaking changes in v28 client interface, which AFAIK will make it unable for the compose to vendor buildx 0.21.

What's the breakage? If there is one, we can already bring in v28 to buildx now. Just need to cut the release branch from current release.

The actual solution for this is to get the PRs calling buildx directly merged in compose so it doesn't need imports.