vtproto is an extra protobuf compiler that generates special methods
suffixed with `VT` that create typed and unrolled marshal and unmarshal
functions similar to gogo that can be used for performance sensitive
code. These extensions are optional for code to use but buildkit uses
them.
A codec is also included to utilize vtproto for grpc code. If the
package `github.com/moby/buildkit/util/grpcutil/encoding/proto` is
imported then vtproto will be used if it exists and otherwise it will
use the standard marshaling and unmarshaling methods.
This codec has an important difference from the default codec. The
default codec will always reset messages before unmarshaling. In most
cases, this is unnecessary and is only relevant for `RecvMsg` on
streams. In most cases, if we are passing in an existing message to this
method, we want to reuse the buffers. This codec will always merge the
message when unmarshaling instead of resetting the input message.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
The relative paths option for protoc generators doesn't work well when
it comes to dependencies. This simplifies the code generation to avoid
using `go generate` and to use one global command for protoc generation.
This is similar to https://github.com/docker/buildx/pull/2713 since the
same problems with code generation occur here too.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Remove gogoproto in favor of the standard protobuf compiler. This
removes any nonstandard extensions that were part of gogoproto such as
the custom types.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
PR #3431 caused connections closed on the remote side of a sshforward
session to not always result in the local side reading an EOF from the
connection. This change restores that behavior by closing the write side
of the forwarded connection after reading an EOF from the stream. Since
only the write side is being closed, it doesn't prevent the remote side
from continuing to read from the connection.
Signed-off-by: Aaron Lehmann <alehmann@netflix.com>
The GRPC docs on RecvMsg say:
> RecvMsg blocks until it receives a message into m or the stream is
> done. It returns io.EOF when the client has performed a CloseSend.
> On any non-EOF error, the stream is aborted and the error contains
> the RPC status.
So if EOF is received that just means the client won't be sending
anymore data. But it may still be expecting to read data, so we
shouldn't close the conn yet.
This was encountered in real life when forwarding a docker socket to a
container, where it appears that the docker CLI closes its write side of
the connection when requesting the stdout/stderr but then expects to
read data after that.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
This package is an alias for "context", which has been part of
stdlib since go1.7, so should no longer be needed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
