A temporary workaround for "http: invalid Host header" introduced in
go 1.20.6.
Signed-off-by: Justin Chadwell <me@jedevc.com>
(cherry picked from commit c4bec05466)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
client: define a "dummy" hostname to use for local connections
fixes "http: invalid Host header" errors when compiling with go1.20.6
or go1.19.11
full diff: https://github.com/docker/docker/compare/v24.0.2...36e9e796c6fc
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
(cherry picked from commit 8a3a646c61)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Although a builder from the store cannot be created unless
it has a valid name, this is not the case for a Docker context.
We should skip name validation when checking a node from the
store and fall back to finding one from Docker context instead.
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
(cherry picked from commit b1c5449428)
We need to resolve the strip the cwd:// prefix before attempting to
resolve the dockerfile. Otherwise, we'll get the cwd:// prefix in the
dockerfile name, which isn't stripped out later.
Signed-off-by: Justin Chadwell <me@jedevc.com>
(cherry picked from commit 431732f5d1)
ReadLocalFiles should allow passing the stdin file as an argument, which
allows us to read from dockerCli.Stdin() to be consistent with other
commands in the same package.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This commit allows specifying a JSON array to the long-form arg, entrypoint and
envvars.
Non-JSON-array value can still be specified. Buildx treats the value as a JSON
array only when it can be parsed as a JSON array.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
When running `--invoke` against images that have `Cmd` set, the interactions with `Entrypoint` start to cause issues like the following:
/usr/local/bin/bash: /usr/local/bin/bash: cannot execute binary file
Or:
sh: can't open 'bash': No such file or directory
This patch fixes those by explicitly setting `Cmd` to be empty if it is unspecified and `Entrypoint` is being set, which matches `docker`'s behavior:
$ docker image inspect --format '{{ json .Config.Entrypoint }} + {{ json .Config.Cmd }}' bash
["docker-entrypoint.sh"] + ["bash"]
$ docker create --name foo --entrypoint bash bash
$ docker container inspect --format '{{ json .Config.Entrypoint }} + {{ json .Config.Cmd }}' foo
["bash"] + null
$ docker rm foo
$ docker create --name foo bash ls
$ docker container inspect --format '{{ json .Config.Entrypoint }} + {{ json .Config.Cmd }}' foo
["docker-entrypoint.sh"] + ["ls"]
(There are still some weird edge cases in the interaction between the `InvokeConfig` and the original image config, but this fixes the most irritating for me and the rest are going to be deeper changes that are possibly less acceptable. 😅)
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
Justin Chadwell