[23.0] vendor: update buildkit to latest v0.10#44959
Conversation
Signed-off-by: Tonis Tiigi <[email protected]>
| github.com/miekg/dns v1.1.43 | ||
| github.com/mistifyio/go-zfs v2.1.2-0.20190413222219-f784269be439+incompatible | ||
| github.com/moby/buildkit v0.10.7-0.20230206124303-b8fdb4b78da0 | ||
| github.com/moby/buildkit v0.10.7-0.20230208155512-4f0ee09c40e2 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
We're not planning to do any actual v0.10 releases anymore, as v0.11 is already out.
There was a problem hiding this comment.
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
added
area/builder
thaJeztah
left a comment
thaJeztah
left a comment
There was a problem hiding this comment.
LGTM
but agreed that it would be good to have a tagged version
neersighted
left a comment
neersighted
left a comment
There was a problem hiding this comment.
Registering my -1 based on the desire for a tagged release, or compelling technical reasons to not prefer one.
|
@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. |
|
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:
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 |
AkihiroSuda
left a comment
AkihiroSuda
left a comment
There was a problem hiding this comment.
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
|
W.r.t. BK v0.10.x, maybe just create a tag on the git repo without releasing binaries? |
neersighted
left a comment
neersighted
left a comment
There was a problem hiding this comment.
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).
|
This fixed #44943 |
5 participants
Brings in moby/buildkit#3595
Signed-off-by: Tonis Tiigi [email protected]