Updating to the lowest release that includes [protobuf@dfab275], which
removed use of the github.com/golang/protobuf/ptypes/timestamp.Timestamp
type alias (deprecated).
[protobuf@dfab275]: dfab275eca
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Removes the `tools/tools.go` file used as a hack to get `go.mod` to
track tools in favor of the new method introduced in go 1.24 of being
formally supported in the `go.mod` file. This will allow the tools to be
managed with the new `go get tool` and `go install tool` commands.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
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>
Combines the shared parts of stacktraces so they
take up less space. For example if error is wrapped
from similar codepath to the main error, the main error
gets the stacktrace and wrapping gets only to stacktrace
up to the point where same frame exists in main error as well.
This also means we need to be less careful about WithStack as
if error already has a longer stack from current position, it
would be ignored.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Use the pkg/errors and stack package interface to check for a stack. Use
the standard library methods to unwrap errors.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Generating the util/stack protos failed when updating protoc-gen-go to v1.5.2;
it looks like this is the only proto that's not generated using protoc-gen-gogo):
util/stack/generate.go
protoc-gen-go: unable to determine Go import path for "stack.proto"
Please specify either:
• a "go_package" option in the .proto source file, or
• a "M" argument on the command line.
See https://developers.google.com/protocol-buffers/docs/reference/go-generated#package for more information.
--go_out: protoc-gen-go: Plugin failed with status code 1.
util/stack/generate.go:3: running "protoc": exit status 1
Newer protobuf versions expect a go package to be set. Other .proto files in
this repository use the bare package name, but with protoc-gen-go v1.5.2, this
produces an error (package names must at least have a "/"). In addition to
including the option to the .proto file also changes the generated result
(`options go_package "<package name>"`).
Using the `-go_opt=M<package name>` option on the other hand, didn't change the
result (while still on protoc-gen-go v1.3.5), so I used that option instead.
protoc-gen-go v1.5.2 also changed the behavior where the generated file is stored,
seemingly relative to the `../../vendor` path specified. This coud be fixed either
by setting `--go_out=../../`, which was a bit counter-intuitive, or setting the
`--go_opt=paths=source_relative` option. The latter also prevented v1.5.2 from
storing the file in `utils/stack/github.com/moby/buildkit/utils/stack/` (sigh).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch updates the script and Dockerfile to prevent issues when using go
modules.
The first change is to use a plain `git clone` instead of `go get -d` to download
the source. While (like "pre go-modules") `go get -d` won't *build* the binaries
when go modules are used, it *will* use go modules to download the package
(and dependencies); as a result:
- no git repository will be cloned in gopath
- go modules will be downloaded for "master" (not the version that we specify
to build)
Note: Once we update to Go 1.16, this script could be updated to use `go install <repo>@version`
The second change is an update to the `update-generated-files` script to detect
the correct version of google/protobuf to use from the `go.mod`'s `replace` rule,
to make sure we generate (and verify) using the correct version.
The Dockerfile was also updated to update the default versions specified in the
PROTOBUF_VERSION and GOGO_VERSION build-args (although not strictly necessary).
Regenerating the files with this version resulted in a minor formatting change.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
