@tonistiigi Let me know if this integration test is enough

curl doesn't show much. We can test that ip a shows different IP for RUN and RUN --net=host.

Looks like there is a bug with bridge network mode and host entitlement:

FROM busybox
RUN ip a
RUN --network=host ip a

$ docker buildx create --name bridge --buildkitd-flags "--debug --allow-insecure-entitlement network.host --oci-worker-net bridge" --driver-opt "image=moby/buildkit:master" --bootstrap
$ docker buildx --builder bridge build --no-cache .
...

#3 [internal] load .dockerignore
#3 transferring context: 2B done
#3 DONE 0.0s
WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
ERROR: failed to solve: failed to load LLB: network.host is not allowed

Why is this adding new option to create instead of just defining a new driveropt?

For me a driver-opt is driver specific (container config for docker-container with docker api, pod specific for k8s api) while buildkitd-(flags|config) is common. I think this would be confusing to put it as driver-opt.

I don't think this is an important enough case to have a special option. Basically, it is only a test option for v0.13. After v0.14, if bridge becomes default we don't expect anyone to ever use this anymore.

After v0.14, if bridge becomes default we don't expect anyone to ever use this anymore.

If we have more network mode in the future that could be valuable I think? Like a wg mode (wireguard) one?

If you don't see this as valuable to keep, I was thinking we could use an env var instead? Something like BUILDKIT_NETMODE or EXPERIMENTAL_BUILDKIT_NETMODE? But current vars https://docs.docker.com/build/building/variables/#build-tool-configuration-variables are not drive for create cmd, only build or bake so might not be ideal 😞

So yeah maybe a driver-opt with a specific description about it saying this is temporary could be ok.

Maybe we should skip it then and just document setting --buildkitd-flags. We can still keep the test.

Maybe we should skip it then and just document setting --buildkitd-flags. We can still keep the test.

Yeah --buildkitd-netmode is more likely a shorthand for --buildkitd-flags="--oci-worker-net=<mode>". I'm fine just documenting --buildkitd-flags to set custom network mode.

Future follow-up: ideally these cases should be handled so that we can test any buildkit version and test can mark itself to be skipped if it doesn't work with specific version.