Pass the exit code through the exited event back to the client and
ensure that the printed text is printed completely.
Previously, the exited event just had a big todo and the printer would
sometimes fail to send messages to the connected client. This moves the
printer wait to before the debug adapter is closed to ensure that all
messages get sent through the connection to the editor. While there, I
also plumbed in the exit code to exited. It's not necessarily the real
exit code but it will produce a zero on build success and a non-zero
code on build failure so that should be good enough.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
The context used for serving the dap server was being canceled too early
because it used defer which would initiate at the end of the function
while every other cleanup function used `t.Cleanup` which executes in
its own goroutine.
One possible solution was to move the cancel to the cleanup, but the
context being passed to serve and start doesn't make sense because if it
ever does get canceled, it'll likely cause a similar race condition with
`Stop`.
This removes the context from the methods that were causing this issue
in favor of just relying on the caller calling `Stop` when they are done
with the adapter and server.
This seems to have only affected tests and I don't believe it affected
the actual dap command.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Properly map the source paths from the metadata in the solve to the
client side paths. The source path returns is relative to the context
that gets uploaded which is usually a subdirectory. The original code
noticed this when mapping the paths but made the invalid assumption that
the dockerfile would always be in the context path so it combined the
dockerfile name with the context path.
It is possible for the dockerfile to be in a subdirectory of the
context. In which case, we computed the paths incorrectly.
This modifies DAP to instead use the `DockerfileMappingDst` and
`DockerfileMappingSrc` which are special included variables to the
inputs that get filled in during the build for the purpose of mapping
the source path to the client side path.
Tests have also been added for this functionality to ensure it doesn't
break again. This should work with both absolute and relative paths
although absolute paths should probably be preferred for usage just
because they're less likely to result in weird things happening.
The sources are also normalized to always convert the source filenames
to absolute paths and DAP itself will accept relative paths but will
only ever communicate in absolute paths. When you set a breakpoint, it
will convert it to an absolute path and reference it in that way rather
than a relative path.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Case insensitive filesystems can cause breakpoints to not be seen or
verified. This is particularly true on Windows where the drive letter
can also participate in the filepath.
Change the detection logic for a breakpoint to be case insensitive. At
the same time, report the name of the source as part of the breakpoint
so that the editor can be told which casing we're expecting to be used.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
When a breakpoint fails to be verified, it will switch the reason to
"failed". It starts off the reason as "pending".
The `reason` field for a breakpoint was added some time after the last
release of `go-dap` which has only been updated once in the last year so
this uses the `main` branch version which contains the field.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This adds integration tests for the `dap build` command to test various
behavior associated with the command. We start the build and the
integration test acts as a dap client to send requests and check that
the output is what we expect.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
The old logic wasn't quite right, and a little hard to follow.
Before this, because breakpoints sent from setBreakpoints don't have an
end line or column they are just a single point the comparison would
fail the check due to the column check.
E.g. if I have a breakpoint on line 30.
The content lines range from 29-31.
Now lets say the end column is at postion 10, but my breakpoint is at
L30 column 11 (still within range).
The overlap check would fail because 11 > 10 but these shouldn't be
compared at all in this case.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
The setBreakpoints response body is defined to be an array of
breakpoints but the debug adapter incorrectly serialized an empty array
as null in the JSON message. Explicitly initializing the array will
force the JSON serialization process to send an empty array back instead
of null.
Signed-off-by: Remy Suen <remy.suen@docker.com>
Invoking the shell will cause it to persist across the entire build and
to re-execute whenever the builder pauses at another location again.
This still requires using `exec` to launch the shell. Launching by frame
id is also removed since it no longer applies to this version.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Change how breakpoints and stepping works. These now work more how you
would expect another programming language to work. Breakpoints happen
before the step has been invoked rather than after which means you can
inspect the state before the command runs.
This has the advantage of being more intuitive for someone familiar with
other debuggers. The negative is that you can't run to after a certain
step as easily as you could before. Instead, you would run to that stage
and then use next to go to the step directly afterwards.
Step in and out also now have different behaviors. When a step has
multiple inputs, the inputs of non-zero index are considered like
"function calls". The most common cause of this is to use `COPY --from`
or a bind mount. Stepping into these will cause it to jump to the
beginning of the call chain for that branch. Using step out will exit
back to the location where step in was used.
This change also makes it so some steps may be invoked multiple times in
the callgraph if multiple steps depend on them. The reused steps will
still be cached, but you may end up stepping through more lines than the
previous implementation.
Stack traces now represent where these step in and step out areas
happen rather than the previous steps. This can help you know from where
a certain step is being used.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Supports using the `evaluate` request in REPL mode to start a container
with the `exec` command. Presently doesn't support any arguments.
This improves the dap server so it is capable of sending reverse
requests and receiving the response. It also adds a hidden command
`dap attach` that attaches to the socket created by `evaluate`.
This requires the client to support `runInTerminal`.
Likely needs some additional work to make sure resources are cleaned up
cleanly especially when the build is unpaused or terminated, but it
should work as a decent base.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Step into and step out are required by the UI for DAP. We don't have a
way to implement these in a logical manner but they need to exist. We'll
discuss in further iterations how these might differ from next and
continue, but for now, we just need some implementation for the UI.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Implement variable references to inspect the state of a stack frame.
Variable reference ids are composed of two sections. A thread mask that
is the first 8 bytes and the remainder is an increasing number that gets
reset each time a thread is resumed. This allows the adapter to know
which thread to delegate the variables request to and allows the
variable references to still remain confined to each thread. An int32 is
used for this because variable references need to be in the range of
(0, 2^32).
At the moment, only the platform variables and some of the exec
operations for an operation. These are labeled as "arguments" to the
stack frame.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Implement the first iteration of breakpoints. When a breakpoint is set,
it starts unverified. When a thread begins evaluation, it tries to see
if a breakpoint corresponds to one of the parsed instructions and will
verify it.
Breakpoints work when continue is used.
At the current moment, setting breakpoints while a thread is currently
running doesn't work. Breakpoints are rechecked each time execution is
about to restart.
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>
Jonathan A. Sternberg