The test was making an assertion that is no longer expected to always be
true after #2195, which purposely made flightcontrol less deterministic.
This lead to occasional failures.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
Previously, the flightcontrol group was being given a key just set to
the ref's ID, which meant that concurrent calls using different values
of compressionType, createIfNeeded and forceCompression would
incorrectly be de-duplicated.
The change here splits up the flightcontrol group into a few separate
calls and ensures that all the correct input variables are put into the
flightcontrol keys.
Signed-off-by: Erik Sipsma <erik@sipsma.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>
The transformation to rootedPatterns seems very wrong and inconsistent
with what the copy logic did. Change it to match the copy logic, and add
more testing.
Signed-off-by: Aaron Lehmann <alehmann@netflix.com>
This adds a little extra testing around ** patterns, and adds a
(currently skipped) test for copying directories under symlinks (#2300).
It removes an extra call to `filepath.FromSlash` in `shouldIncludePath`
and an unused argument to that function.
Signed-off-by: Aaron Lehmann <alehmann@netflix.com>
In preparation of replacing the deprecated github.com/docker/docker/pkg/signal,
which uses this version (updating it separately for easier review).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This will allow clients to retrieve exit error codes returned during a
solve without parsing the error messages.
Signed-off-by: Aaron Lehmann <alehmann@netflix.com>
This import comment caused compilation of buildx to fail if `GO111MODULE` was
set to `off`:
Without `GO111MODULE` set (but with `-mod=vendor`:
echo $GO111MODULE
export PKG=github.com/docker/buildx
export LDFLAGS="-X ${PKG}/version.Version=$(git describe --match 'v[0-9]*' --always --tags) -X ${PKG}/version.Revision=$(git rev-parse HEAD) -X ${PKG}/version.Package=${PKG}"
GOFLAGS=-mod=vendor go build -o bin/docker-buildx -ldflags "${LDFLAGS}" ./cmd/buildx
bin/docker-buildx version
github.com/docker/buildx v0.6.0 d9ee3b134cbc2d09513fa7fee4176a3919e05887
When setting `GO111MODULE=off`, it fails on the incorrect import path in the
vendored file (looks like GO111MODULE=on ignores import-path comments?):
export GO111MODULE=off
root@5a55ec1c1eed:/go/src/github.com/docker/buildx# GOFLAGS=-mod=vendor go build -o bin/docker-buildx -ldflags "${LDFLAGS}" ./cmd/buildx
vendor/github.com/moby/buildkit/client/client.go:20:2: code in directory /go/src/github.com/docker/buildx/vendor/github.com/moby/buildkit/util/tracing/otlptracegrpc expects import "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
vendor/go.opentelemetry.io/otel/exporters/otlp/otlptrace/internal/connection/connection.go:33:2: found import comments "go.opentelemetry.io/otel/exporters/otlp/internal/otlpconfig" (options.go) and "go.opentelemetry.io/otel/exporters/otlp/otlptrace/internal/otlpconfig" (optiontypes.go) in /go/src/github.com/docker/buildx/vendor/go.opentelemetry.io/otel/exporters/otlp/otlptrace/internal/otlpconfig
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Tõnis Tiigi
Erik Sipsma
Cory Bennett
Akihiro Suda
Sebastiaan van Stijn
Akihiro Suda
Aaron Lehmann
Koichi Shiraishi
CrazyMax
CrazyMax
CrazyMax
Anders F Björklund
dependabot[bot]
Sebastiaan van Stijn