Right now if an exec fails the graphql error just says that it exited non-zero. This makes it hard to debug unless you go look at the buildkit progress output.
We should instead include the output of the execop in the graphql error to help debugging. The implementation is not incredibly straightforward. Buildkit has the ability to obtain the FS of a failed exec op (including changes made during the command): https://github.com/moby/buildkit/blob/c9a0f4d2de095591e742d7f411d9ed36a03a1c4e/client/build_test.go#L1278-L1310
We will probably need to use that to obtain the output as written to the output files by the shim.
We should also make sure to limit the size of the output included so if there's a failure during a command with many megabytes of output (e.g. compiling a large project) we don't try to transfer all of that in the error. Instead, we can just return the last N bytes.
Right now if an exec fails the graphql error just says that it exited non-zero. This makes it hard to debug unless you go look at the buildkit progress output.
We should instead include the output of the execop in the graphql error to help debugging. The implementation is not incredibly straightforward. Buildkit has the ability to obtain the FS of a failed exec op (including changes made during the command): https://github.com/moby/buildkit/blob/c9a0f4d2de095591e742d7f411d9ed36a03a1c4e/client/build_test.go#L1278-L1310
We will probably need to use that to obtain the output as written to the output files by the shim.
We should also make sure to limit the size of the output included so if there's a failure during a command with many megabytes of output (e.g. compiling a large project) we don't try to transfer all of that in the error. Instead, we can just return the last N bytes.