It is now possible to send next and continue as separate signals. When
executing a build, the debug adapter will divide the LLB graph into
regions. Each region corresponds to an uninterrupted chain of
instructions. It will also record which regions depend on which other
ones.
This determines the execution order and it also determines what the
stack traces look like.
When continue is used, we will attempt to evaluate the last leaf node
(the head). If we push next, we will determine which digest would be the
next one to be processed.
In the future, this will be used to also support breakpoints.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Adds a simple implementation of the debug adapter that supports the very
basics of a debug adapter.
It supports the launch request, the configuration done request, the
creation of threads, stopping, resuming, and disconnecting from server.
It does not support custom breakpoints, stack traces, or variable
inspection yet. These are planned to be added in the future.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This changes the build handler to customize the behavior of evaluate
rather than onresult and also simplifies the `ResultHandle`. The
`ResultHandle` is now only valid within the gateway callback and can be
used to start containers from the handler.
`Evaluate` now executes inside of the gateway callback rather than
having a separate implementation that executes or re-invokes the build.
This keeps the gateway callback session open until the debugger has
returned.
The `ErrReload` for monitor has now been moved into the `build` package
and been renamed to `ErrRestart`. This is because it restarts the build
so the name makes a bit more sense. The actual use of this functionality
is still tied to the monitor reload.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This changes the progress printer's pause and unpause implementation to
be reentrant to prevent race conditions and it also allows the status
updates to be buffered when the display is paused.
The previous implementation mixed the pause implementation with the
finish implementation and could cause a send on closed channel panic
because it could close the status channel before it had finished being
used. Now, the status channel is not closed.
When the display is enabled, the status channel will be forwarded to an
internal channel that is used to display the updates. When the display
is paused, the status channel will have the statuses buffered in memory
to be sent when the progress display is resumed.
The `Unpause` method has also been renamed to `Resume`.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
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>
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>
Remove the controller grpc service along with associated code related to
sessions or remote controllers.
Data types that are still used with complicated dependency chains have
been kept in the same package for a future refactor.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Removes gogo/protobuf from buildx and updates to a version of
moby/buildkit where gogo is removed.
This also changes how the proto files are generated. This is because
newer versions of protobuf are more strict about name conflicts. If two
files have the same name (even if they are relative paths) and are used
in different protoc commands, they'll conflict in the registry.
Since protobuf file generation doesn't work very well with
`paths=source_relative`, this removes the `go:generate` expression and
just relies on the dockerfile to perform the generation.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.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>
This commit moves monitor commands to `monior/commands` package.
Commands still need access to the `monitor` object and buildx controller so this
commit enables this via `Monitor` interface stored in `monitor/types`.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
Refactor the progress printer creation to the caller-side of the
controller api. Then, instead of passing around status channels (and
progressMode strings), we can simply pass around the higher level
interface progress.Writer.
This has a couple of benefits:
- A simplified interface to the controller
- Allows us to correctly extract warnings out of the controller, so that
they can be displayed correctly from the client side.
Some extra work is required to make sure that we can pass a
progress.Printer into the debug monitor. If we want to keep it
persistent, then we need a way to temporarily suspend output from it,
otherwise it will continue printing as the monitor is prompting for
input from the user, and forwarding output from debug containers.
To handle this, we add two methods to the printer, `Pause` and
`Unpause`. `Pause` acts similarly to `Wait`, closing the printer, and
cleanly shutting down the display - however, the printer does not
terminate, and can later be resumed by a call to `Unpause`. This
provides a neater interface to the caller, instead of needing to
continually reconstruct printers for every single time we want to
produce progress output.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Now clients can access the result of the solve, specifically the image
id output. This is a useful refactor, as well as being required if we
want to allow bake to invoke through the controller api.
This also allows us to remove the quiet option from the API, since we
can compute the required progress type outside of the controller, and
can print the image id from the result of the solve.
As a follow-up, we should also be able to remove the image id file
output from the controller api, now that the client has access to it.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Jonathan A. Sternberg
Jonathan A. Sternberg
Tonis Tiigi
Talon Bowler
Kohei Tokunaga
Tianon Gravi
Justin Chadwell