Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Windows buildkit required features #365

Open
3 tasks
junglie85 opened this issue Nov 7, 2024 · 6 comments
Open
3 tasks

Tracking Windows buildkit required features #365

junglie85 opened this issue Nov 7, 2024 · 6 comments

Comments

@junglie85
Copy link

junglie85 commented Nov 7, 2024

Experimental Windows support was released in version 0.13.0 of buildkit and details of how to use are in a blog entry.

This is a great step on the way to being able to unify Windows and Linux build processes.

What are the missing features in buildkit that are needed before unification can happen? Perhaps we could track them in this issue?

Required features:

Nice to have features:

  • buildkit support implemented for docker buildx build instead of manually calling containerd and buildkitd
@slonopotamus
Copy link
Collaborator

slonopotamus commented Nov 7, 2024

I'm not sure we want to directly call buildkitd. Instead, it would be much more convenient if Windows + buildkit support was implemented for docker buildx build (that we already use and would just need to adjust our code a little: https://github.com/moby/moby/blob/v27.3.1/builder/builder-next/executor_nolinux.go#L25)

@TBBle
Copy link
Collaborator

TBBle commented Nov 7, 2024

Well, then we can mark down "integration into buildx" as an example of a feature we're waiting for, which is mostly in the moby builder-next support, or alternatively if someone gets the docker-container or one of the remote drivers working, that'd work too.

Off-hand, the only other thing that we care about that is new in buildx is the --secret flag, i.e. moby/buildkit#5273 says that's not available yet, and AFAIR that's our primary motivator for using buildx/BuildKit.

@slonopotamus
Copy link
Collaborator

slonopotamus commented Nov 7, 2024

the only other thing that we care about that is new in buildx is the --secret flag

We also care about cache-mounts that only work with buildkit.

@TBBle
Copy link
Collaborator

TBBle commented Nov 7, 2024

Good point. As it happens, that's the same ticket, I suspect, in the general sense of "Get everything in https://github.com/moby/buildkit/blob/master/solver/llbsolver/mounts/mount.go working on WIndows". I'm not sure how cache mounts work at the implementation level, but all the other mounts in that file currently utilise tmpfs in some way or other, and we don't have a Windows equivalent for that AFAIK.

@slonopotamus
Copy link
Collaborator

I believe cache mounts are just binds.

@junglie85
Copy link
Author

junglie85 commented Nov 8, 2024

I'm not sure we want to directly call buildkitd.

I'm hopeful that longer term this wouldn't be needed. But I don't see why ue4-docker would need to directly call buildkitd. Until buildkit is better integrated into Docker on Windows, starting containerd and buildkitd, and creating a builder could be a pre-requesite to running ue4-dockeer.

the only other thing that we care about that is new in buildx is the --secret flag, i.e. moby/buildkit#5273

This is probably a bigger blocker, given the statement that they don't plan to implement this until the classic builder has feature parity.

I believe cache mounts are just binds.

I can't find confirmation of this in the docs. @slonopotamus do you know where this can be confirmed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants