Adds some entry-level and developer-friendly docs for the debug adapter.
The one in `docs/dap.md` is meant for someone trying to use the debugger
while the one in `docs/reference/buildx_dap_build.md` is more focused on
documenting the command to be integrated in a debugger extension.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This will configure the default behavior when beginning to evaluate a
build target. When `stopOnEntry` is used, it will default to `stepNext`.
Otherwise, `stepContinue` will be used.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
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>
While it would make sense to add "from file" to complement "from env,"
(in the common case of `--file` or using the default), it wouldn't
provide any real value.
A simpler solution would have been looking for the existence of the
variable at the point where printing happens. It felt wrong
duplicating the logic. Executing the same logic (if it was extracted)
wouldn't be as bad, but still not ideal.
A 'correct' solution would be to explicitly track the source of each
definition, which would be clearer and more future-proof. It didn't
seem like this feature warranted that amount of engineering (with no
known features that might make use of it).
This implementation seemed like a fair compromise; none of the functions
are exported, and all have only one caller.
I also considered converting prefixing environment values with `env://`
so they could be thought of (and processed like) `cmd://` values. I
didn't think it would be viewed as a good solution.
Co-authored-by: CrazyMax <1951866+crazy-max@users.noreply.github.com>
Signed-off-by: Roberto Villarreal <rrjjvv@yahoo.com>
Jonathan A. Sternberg