Removes all references to the controller and moves the remaining
sections of code to other packages.
Processes has been moved to monitor where it is used and the data
structs have been removed so buildflags is used directly. The controller
build function has been moved to the commands package.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
If a type was explicitly provided, it will be displayed in the variable
listing. Inferred type names are not displayed, as they likely would
not match the user's intent.
Previously only `string` and `bool` default values were displayed in the
listing. All default values, regardless of type, are now displayed.
Signed-off-by: Roberto Villarreal <rrjjvv@yahoo.com>
A variable with a type but no default value or override resulted in an
empty string. This matches the legacy behavior of untyped variables,
but does not make sense when using types (an empty string is itself a
type violation for everything except `string`). All variables defined
with a type but with no value are now a typed `null`.
A variable explicitly typed `any` was previously treated as if the
typing was omitted; with no defined value or override, that resulted in
an empty string. The `any` type is now distinguished from an omitted
type; these variables, with no default or override, are also `null`.
In other respects, the behavior of `any` is unchanged and largely
behaves as if the type was omitted. It's not clear whether it should be
supported, let alone how it should behave, so these tests were removed.
It's being treated as undefined behavior.
Signed-off-by: Roberto Villarreal <rrjjvv@yahoo.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>
There was inconsistency between variables used for function
definitions in HCL and JSON format. Updated JSON to match HCL,
fixed documentation and removed the unused code from userfunc
pkg (based on HCL upstream) to avoid confusion.
Theoretically we could add some temporary backwards compatibility
for the JSON format but I think it is unlikely that someone uses
JSON format for this and also defined variadic parameters.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Annotations were not merged correctly. The overrides in `ArrValue` would
be merged, but the section of code setting them from the command line
did not include `annotations` in the list of available attributes so the
command line option was completely discarded.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Allow access to CDI Devices in Buildkit v0.20.0+ for
devices that are not automatically allowed to be used by
everyone in BuildKit configuration.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Signed-off-by: CrazyMax <1951866+crazy-max@users.noreply.github.com>
Update the buildflags cty code to handle unknown values. When hcl
decodes a value with an invalid variable name, it appends a diagnostic
for the error and then returns an unknown value so it can continue
processing the file and finding more errors.
The iteration code has now been changed to use a rangefunc from go 1.23
and it skips empty or unknown values. Empty values are valid when they
are skipped and unknown values will have a diagnostic for itself.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Guillaume Lours