When following this pattern:
buildx build --arg FOO
Where we want to pull `FOO` from env, currently we always set `FOO`
regardless if the `FOO` env var is even set.
This change makes it so that `FOO` would only be set if it has been set
in the env (even if it is set to empty).
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Getting the QEMU interpreters to work transparently inside containers seems to be a bit of a sticking point, with major distributions still on kernels and/or binfmt-support package versions that don't support the fix_binary flag yet. Give the reader a little more guidance what to look out for.
When booting `docker-container` driver, it will pull and run image
`moby/buildkit:buildx-stable-1`.
If current node cannot connect to dockerhub, driver `docker-container`
will always booting failure.
But user may already load the image manually or pull it from a priviate
registry.
Buildx should check local docker image store after pull failed.
Fixes: #199 issuecomment-561996661
Signed-off-by: Lu Jingxiao <lujingxiao@huawei.com>
Tested with `kind` and GKE.
Note: "nodes" shown in `docker buildx ls` are unrelated to Kubernetes "nodes".
Probably buildx should come up with an alternative term.
Usage:
$ kind create cluster
$ export KUBECONFIG="$(kind get kubeconfig-path --name="kind")"
$ docker buildx create --driver kubernetes --driver-opt replicas=3 --use
$ docker buildx build -t foo --load .
`--load` loads the image into the local Docker.
Driver opts:
- `image=IMAGE` - Sets the container image to be used for running buildkit.
- `namespace=NS` - Sets the Kubernetes namespace. Defaults to the current namespace.
- `replicas=N` - Sets the number of `Pod` replicas. Defaults to 1.
- `rootless=(true|false)` - Run the container as a non-root user without `securityContext.privileged`. Defaults to false.
- `loadbalance=(sticky|random)` - Load-balancing strategy. If set to "sticky", the pod is chosen using the hash of the context path. Defaults to "sticky"
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Move a paragraph in README to clarify where it fits in the structure.
- Before the move, the paragraph seems to apply to the `--output=local` section when in fact it applies to the entire `--output` section. This is especially confusing for the sentence "if just the path is specified as a value, `buildx` will use the local exporter with this path as the destination".
- After the move, it is clear that the paragraph applies to `--output`
This works just like the `build` command where if you have `--build-arg
FOO`, it will read the variable from env and only set a value if the
variable is defined.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Brian Goff