This commit adds the IDE-integrated breakpoint debugger based on walker.
Now buildx provides DAP (Debug Adapter Protocol) API to IDEs so DAP-aware IDEs
can call buildx and allow users to perform breakpoint-based debugging on the
IDE's UI/UX.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
This commit adds a set of commands to monitor for enabling breakpoint debugger.
This is implemented based on the walker utility for step-by-step LLB inspection.
For each vertex and breakpoint, monitor calls Solve API so the user can enter to
the debugger container on each vertex for inspection.
User can enter to the breakpoint debugger mode by --invoke=debug-step flag.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
This commit adds two fields to the response of Inspect API.
- Definition: Build definition of the first build executed by Build API.
- CurrentDefinition: Build definition of the latest build executed by Build or
Solve API.
The client can use these information for debugging the build deeply.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
This commit adds Solve API to the controller. This receives a build definition,
performs that build using ResultHandler held by that session. After Solve
completes, the client can debug the result using other APIs including Invoke.
Note that the ResultHandle provided by Solve overwrites the ResultHandle
previously stored in that session (possibly generated by the past Build or Solve
API call).
Using this API, user can perform build-and-debugging loop on the same session.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
This commit adds BuildOptions.Debug that allows skipping the evaluation of the
ResultHandler. The ResultHandler is created without evaluated, so calling Build
API with this flag always returns an error with the reference ID of that
(errored) ResultHandler. Note that this state of ResultHandler doesn't contain
result nor error so any operation on that ResultHandler will result in an error.
Following commit will allow user to do further operations (e.g. evaluation of a
bulid) using the buildkit client held by that ResultHandler.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
Fixed in 12b6a3ad9a, but now we have
regression tests! So we can add a check that we don't break this
behavior again.
Signed-off-by: Justin Chadwell <me@jedevc.com>
- Adds a new GitServeHTTP function to start an http server to serve a
target git repository.
- Adds a new GitDir helper method to get the path to the .git
directory
- Updates the GitAdd method to take a variable number of files
Signed-off-by: Justin Chadwell <me@jedevc.com>
Now, we always perform the full solve request in the main gateway call.
This ensures that progress works properly, and makes the lifetime
semantics much clearer.
NewResultContext abstracts the details of a successful/failed build, to
always return a single ResultContext, even though the details of how a
gateway is created is different:
- For a failed build, we can just keep the gateway open.
- For a successful build, we immediately open another gateway and
re-evaluate the build definition in that gateway. This should give an
instant cache hit (since the build was just successful).
Signed-off-by: Justin Chadwell <me@jedevc.com>
Kohei Tokunaga