Estargz support has been removed from this test as
implementation does not guarantee digest stability
and only reason it passed were the exceptions in the
test via variant map that ignored cases where timing
resulted the digest to go wrong. This needs to be
addressed in the follow up if we want to keep estargz
support.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
After go1.17, all indirect packages are listed in the go.mod file.
In addition, has been introduced the ability to list indirect packages separately.
Split the indirect packages to make the dependency packages clearer.
Signed-off-by: Koichi Shiraishi <zchee.io@gmail.com>
This replaces the local SeccompSupported() utility for the implementation
in containerd, which performs the same check.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
There are a few goals with this refactor:
1. Remove external access to fields that no longer make sense and/or
won't make sense soon due to other potential changes. For example,
there can now be multiple blobs associated with a ref (for different
compression types), so the fact that you could access the "Blob"
field from the Info method on Ref incorrectly implied there was just
a single blob for the ref. This is on top of the fact that there is
no need for external access to blob digests.
2. Centralize use of cache metadata inside the cache package.
Previously, many parts of the code outside the cache package could
obtain the bolt storage item for any ref and read/write it directly.
This made it hard to understand what fields are used and when. Now,
the Metadata method has been removed from the Ref interface and
replaced with getters+setters for metadata fields we want to expose
outside the package, which makes it much easier to track and
understand. Similar changes have been made to the metadata search
interface.
3. Use a consistent getter+setter interface for metadata, replacing
the mix of interfaces like Metadata(), Size(), Info() and other
inconsistencies.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
This is important for two reasons:
1) Keeps caching logic consistent with recent fsutil changes to use
these functions (also vendored here).
2) Allows us to move forward with removal of the original buggy Matches
implementation in moby/moby.
Signed-off-by: Aaron Lehmann <alehmann@netflix.com>
The BurntSushi/toml project has been deprecated, and the ecosystem
is converging on using pelletier/go-toml as the "canonical" replacement.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
As discussed in #2300, includedPaths does not resolve symlinks when
looking up the source path in the prefix tree. If the user requests a
path that involves symlinks (for example, /a/foo when a symlink /a -> /b
exists), includedPaths will not find it, and will expect nothing to be
copied. This does not match the actual copy behavior implemented in
fsutil, which will follow symlinks in prefix components of a given path,
so it can end up caching an empty result even though the copy will
produce a non-empty result, which is quite bad.
To fix this, use getFollowLinks to resolve the path before walking it.
In the wildcard case, this is done to the non-wildcard prefix of the
path (if any), which matches the behavior in fsutil.
Fixes the repro case here:
https://gist.github.com/aaronlehmann/64054c9a2cff0d27e200cc107bba3d69Fixes#2300
Signed-off-by: Aaron Lehmann <alehmann@netflix.com>
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>
Tonis Tiigi
CrazyMax
Morlay
Aaron Lehmann
Akihiro Suda
Koichi Shiraishi
Sebastiaan van Stijn
Kohei Tokunaga
Erik Sipsma
Cory Bennett
Akihiro Suda