While lsBuilder has a field called Current that gets lost
because the embedded struct implements custom MarshalJSON method.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
The primary intent is to make JSON parsing explicitly opt-in rather than
using heuristics to determine intent.
With some exceptions, given bake variable `VAR`, an environment variable
`VAR_JSON` must be used to provide JSON content. The value in
`VAR_JSON` will be ignored when:
* a bake built-in of that same name exists
* a user-provided variable of that same name exists
* typing (attribute `type`) is not present
The first is unlikely to happen as built-ins will likely start with
`BUILDX_BAKE_`, an unlikely prefix for end users. The second may be a
real scenario, where users have `VAR_JSON` dedicated to accepting a
string with JSON content and decoding via an HCL function. This will
continue to work as-is, but can be simplified by removing the variable
from their bake file (`VAR_JSON`) and applying typing (to `VAR`).
Signed-off-by: Roberto Villarreal <rrjjvv@yahoo.com>
Though CSV is favored for 'simple' lists, a JSON value will be used if
it parses without error. This assumes that it is extremely unlikely
that something that parses as JSON would be intended to be parsed as
CSV, e.g. `["a"` and `"b"]`, as opposed to `a` and `b`. If
parsing/conversion fails, it is treated as if it was a CSV.
Since the CSV approach required processing of each element, code was
refactored to reuse the same logic used for individual non-typed
variables.
Signed-off-by: Roberto Villarreal <rrjjvv@yahoo.com>
This allows variables to have explicit types, similar to Terraform
variables. It uses HCL's `typeexpr` extension for the specification.
For conversion of overrides to complex types (when explicit typing is
provided), HCL's native JSON-based unmarshalling is used.
Typing is independent of any default, but if a default is provided, it
will be validated. Similarly, if an override is provided, it will be
converted to that type.
When typing is not provided, previous behavior is used, namely
passing through as a string when no default, converting to primitives if
the default was primitive, and failing otherwise (complex types).
For complex types, the happy path is lists of primitives, but in theory
any complex/composite type can be used provided they are expressed
correctly in JSON. In the interest of simplicity and correctness, there
are no shortcuts for lists. There *is* a shortcut for strings as users
don't provide them for untyped variables and would be unintuitive.
Signed-off-by: Roberto Villarreal <rrjjvv@yahoo.com>
Prior to this change, the following command emits the wrong image ID when buildx
uses the "docker-container" driver and Docker is configured with the
containerd-snapshotter.
$ docker buildx build --load --iidfile=img.txt
$ docker run --rm "$(cat img.txt)" echo hello
docker: Error response from daemon: No such image: sha256:4ac37e81e00f242010e42f3251094e47de6100e01d25e9bd0feac6b8906976df.
See 'docker run --help'.
The problem is that buildx is outputing the incorrect image ID in this scenario
(it's outputing the container image config digest, instead of the container
image digest used by the containerd-snapshotter).
This commit fixes this. See https://github.com/moby/moby/issues/45458.
Signed-off-by: Cesar Talledo <cesar.talledo@docker.com>
CrazyMax