[23.0] vendor: update buildkit to latest v0.10

[tonistiigi]

Brings in moby/buildkit#3595

Signed-off-by: Tonis Tiigi tonistiigi@gmail.com

[neersighted]

I'd like to have a tagged release for this fix if possible, but I'm not familiar with the process in BuildKit. Are we able to complete a release before this revendoring?

[tonistiigi]

We're not planning to do any actual v0.10 releases anymore, as v0.11 is already out.

[neersighted]

I'm really not sure how I feel about that -- this is a correctness fix for a bug in BuildKit and not a simple revendor. It really feels like there should be a tagged release, instead of us floating off the unreleased tip of the 0.10.x branch indefinitely...

[thaJeztah]

LGTM

but agreed that it would be good to have a tagged version

[neersighted]

Registering my -1 based on the desire for a tagged release, or compelling technical reasons to not prefer one.

[tonistiigi]

@neersighted Moby is like any other downstream for BuildKit. If somebody using buildkit needs to vendor a historic commit, we will not make a release for them. It has own release schedule and policy on what goes into releases. This was exactly the same for the v0.8 branch for any 20.10 releases that happened after BuildKit v0.9 was already out. If downstream doesn't like this, the option is to fork and manage own patches. Until the patches are reasonable, this is not needed, as BK maintainers will happily merge them even if the release has already been superseded.

[neersighted]

This sounds like a weird twilight state in between "we don't maintain anything but the latest branch" and "we accept backports for older branches." Doing code review/gatekeeping what makes it into a previous release branch, but not cutting releases off that branch, seems like a very odd distinction to me (compare this to SwarmKit, which just does not do releases).

I don't necessarily want to block an important fix over reviewing/reconsidering BuildKit release policy, but frankly I don't understand the reasoning and it seems borderline user-hostile to me.

While it's not compelling from a technical standpoint, "This is how we've always done it" does carry weight and I can stifle some of my objections on that basis. However, it was mentioned:

It has own release schedule and policy on what goes into releases.

Where can I see that policy? If it's informal/was never codified beyond convention between maintainers, that does make me want to push back and ask for it to be reconsidered more.

---

Overall, having tagged releases makes it easier to reason about what code is being consumed by Moby, and helps with both provenance concerns as well as diagnostics (e.g. a untagged commit could actually come off of a PR branch and still say moby/buildkit). I really feel it would be best practice here to provide patch releases, or simply force us to maintain a soft fork and manage things as we please there.

[AkihiroSuda]

I think it is ok to have a new release for v0.10.x, but the current v23 branch of Moby already uses an untagged commit of BuildKit, so I guess we can just merge this PR now and discuss releasing BK v0.10.x later

[AkihiroSuda]

W.r.t. BK v0.10.x, maybe just create a tag on the git repo without releasing binaries?

[neersighted]

LGTM given we've agreed to discuss the release lifecycle and see if we can come up with something more beneficial for both projects (which might just be the status quo -- the only commitment I'd like to see is talking about it).

[neersighted]

This fixed #44943