This fixes panics in the moby integration of buildkit when using cache.
Panics come from nil Differ in computeBlobChain which is called in GetRemote().
GetRemote() got moved from Worker to ImmutableRef during the lazy-pull refactor.
However, the ability to easily override GetRemote() got lost with that refactor.
This patch attempts to allow for the override while keeping changes minimal.
Signed-off-by: Tibor Vass <tibor@docker.com>
The existing code was spuriously failing unit tests, because it was
stripping non-permission bits off the file mode.
On examination, the behaviour was inherited from similar code in
moby/moby, which was intended to affect the resulting filemodes inside
a Linux-based container built from Windows. However, this code path does
have that effect in BuildKit as we are only calculating checksums here.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Containerd's mounter doesn't yet support bind-mounts on Windows.
BuildKit short-cuts this for read-write mounts, but not read-only
mounts.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Before this change, walkAllResults did not skip an item if it had already been
visited, so walking the graph of results actually followed every single possible
path in the graph instead of just visiting each item once.
On small graphs this wasn't noticeable, but on sufficiently large remote cache
imports this rapidly scaled out of control. For example, I first encountered
this when importing a max-cache from a build of a full linux rootfs from source
(which takes about 30 minutes to build w/out cache on an 18-core machine) and
after 30 minutes the cache import was still running with all CPUs pegged at 100%
To fix this, walkAllResults now keeps a map of already visited items (keyed by
their pointer) and skips visiting an item if it's already been visited, making
it usable on large remote cache imports.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
There are a few bugs in the image export related code being fixed here.
GetMediaTypeForLayers was iterating over diffPairs in the wrong order, resulting
in it always returning nil for images with more than one layer. This actually
worked most of the time because it accidentally triggered a separate codepath
meant to handle v0.6 migrations where mediatypes left empty get filled in.
However, fixing that bug revealed another existing bug where the "oci" parameter
in the image exporter was not being honored except when the v0.6 codepath got
followed, resulting in images to always have oci layer media types even when
docker types are used for the rest of the image descriptors.
Due to the interaction between these various bugs, the only practical end effect
previously was that single-layer images could use the wrong layer media type. An
existing test has been expanded to cover that case in a previous commit.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
```
[5/5] RUN --mount=target=/go/src/github.com/moby/buildkit gometalinter ...
0.435 util/rootless/specconv/specconv_linux.go:1:⚠️ file is not goimported (goimports)
1.320 cache/manager.go:1:⚠️ file is not goimported (goimports)
1.335 cache/manager_test.go:1:⚠️ file is not goimported (goimports)
1.337 cache/migrate_v2.go:1:⚠️ file is not goimported (goimports)
1.342 cache/refs.go:1:⚠️ file is not goimported (goimports)
1.454 cache/remotecache/registry/registry.go:1:⚠️ file is not goimported (goimports)
2.285 cmd/buildctl/build.go:1:⚠️ file is not goimported (goimports)
3.082 executor/oci/user.go:1:⚠️ file is not goimported (goimports)
4.333 session/content/content_test.go:1:⚠️ file is not goimported (goimports)
4.614 snapshot/containerd/content.go:1:⚠️ file is not goimported (goimports)
4.721 solver/errdefs/vertex.go:1:⚠️ file is not goimported (goimports)
6.066 util/network/cniprovider/cni.go:1:⚠️ file is not goimported (goimports)
ERROR: executor failed running [/bin/sh -c gometalinter --config=gometalinter.json ./...]: buildkit-runc did not terminate successfully
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>