This creates a `Monitor` type that keeps the global state between
monitor invocations and allows the monitor to exist during the build so
it can be utilized for callbacks.
The result handler is now registered with the monitor during the build
and `Run` will use the result if it is present and the configuration
intends the monitor to be invoked with the given result.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
The build now happens in a loop and the monitor is run after every
build. The monitor can return `ErrReload` to signal to the main thread
that it should reload the build result.
This will be used in the future to move the monitor into a callback
rather than as a separate existence. It allows the monitor to not
control the build itself which now makes it possible to completely
remove the controller.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
The monitor needs stdin to run and isn't compatible with loading a
context or dockerfile from stdin. We already disallow this combination
and, with the removal of the remote controller, there's no way to use
stdin during the build when invoke is configured.
This just removes the extra code to allow forwarding stdin to the build
when the monitor is configured to simplify that section of code.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
The controller interface is removed and the local controller is used for
only the initial build, invoke, and rebuilds.
Process control has been moved to the monitor.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
The `--keep-storage` flag was changed to `--reserved-space`. Before it was
changed to that name, it was changed to `--max-storage`. This flag never
made it into a release as the name was changed before release, but the
update to the flag in buildx forgot to update the deprecation notice.
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>
With the removal of the protobuf for the controller, there are no longer
any generated files. Remove the makefile targets and the associated
dockerfiles and bake targets.
This wasn't being included in CI because it wasn't part of the
`validate` target.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.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>
