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>
Fixed in 12b6a3ad9a, but now we have
regression tests! So we can add a check that we don't break this
behavior again.
Signed-off-by: Justin Chadwell <me@jedevc.com>
- Adds a new GitServeHTTP function to start an http server to serve a
target git repository.
- Adds a new GitDir helper method to get the path to the .git
directory
- Updates the GitAdd method to take a variable number of files
Signed-off-by: Justin Chadwell <me@jedevc.com>
Now, we always perform the full solve request in the main gateway call.
This ensures that progress works properly, and makes the lifetime
semantics much clearer.
NewResultContext abstracts the details of a successful/failed build, to
always return a single ResultContext, even though the details of how a
gateway is created is different:
- For a failed build, we can just keep the gateway open.
- For a successful build, we immediately open another gateway and
re-evaluate the build definition in that gateway. This should give an
instant cache hit (since the build was just successful).
Signed-off-by: Justin Chadwell <me@jedevc.com>
