Return args order is not guaranteed (since we use a map internally), so
we need to make sure the test does not rely on order of returns.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Previously, we attempted to gracefully resolve duplicate cache export
options, however, we should explicitly error - a client has made an
error if the same options appear twice. If we really want
de-duplication, then clients such as buildx should implement it there.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Change how provenance information is captured from builds.
While previously frontend passed the buildinfo
sources with metadata, now all information is captured
through buildkit. A frontend does not need to implement
buildinfo and can't set incorrect/incomplete buildinfo
for a build result.
All LLB operations can now collect as much provenance
info as they like that will be used when making the
attestation. Previously this was limited to a single Pin
value. For example now we also detect secrets and SSH IDs
that the build uses, or if it accesses network, if local
sources are used etc.. The new design makes sure this
can be easily extended in the future.
Provenance capture can now detect builds that do
multiple separate subsolves in sequence. For example,
first subsolve gathers the sources for the build and
second one builds from immutable sources without a
network connection. If first solve does not participate
in final build result it does not end up in provenance.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Allows reproducible timestamps for layer and image timestamps.
Implemented as a frontend-opt because in the future same
option could be detected by frontend for custom behavior
and same value should also apply timestamps for FileOps.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
The list of arguments for llbsolver.New() was a bit unwieldy, and
made it unclear what each of the arguments was for, so I wondered
if it would make sense to either define an Opt struct for this, or
to implement functional arguments (which could be an alternative).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
I noticed we were not handling errors in the integration in Moby, and looking
at the code in BuildKit, it appears this never returned an error, and no error
handling was present in BuildKit itself.
This function was added in 45bcca5c80, and never
returned an error at the time, so possibly this was anticipating "for future use",
but 5 years have passed, so perhaps that will never happen :)
Coincidentally, this also makes implement the `session.Attachable` interface in:
1c037fd52f/session/session.go (L32-L35)
// Attachable defines a feature that can be exposed on a session
type Attachable interface {
Register(*grpc.Server)
}
(Not sure if that's a "good" thing or a "bad" thing)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This allows clients to specify that LLB states should be grouped in
progress output under a custom name. Status updates for all vertexes in
the group will show up under a single vertex in the output.
The intended use cases are for Dockerfile COPY's that use MergeOp as a
backend and for grouping some other internal vertexes during frontend
builds.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
This consists of just the base MergeOp with support for merging LLB
results that include deletions using hardlinks as the efficient path
and copies as fallback.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
Export:
$ buildctl build ... --export-cache type=local,store=/path/to/output-dir
Import:
$ buildctl build ... --import-cache type=local,store=/path/to/input-dir
Impact on CLI:
* Old (deprecated but still effective): `--export-cache localhost:5000/myrepo:buildcache --export-cache-opt mode=max`
* New: `--export-cache type=registry,ref=localhost:5000/myrepo:buildcache,mode=max`
Impact on API:
* New fields are added to control.proto and gateway.proto. The daemon
internally translates old API calls to the new ones.
* While new API can be used for `registry` caches, the client continues
to use the legacy API for `registry` caches to ensure compatibility with
old daemons.
* To import `local` caches with a frontend, the frontend needs to support
a new frontend opt `cache-imports`.
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
The alternative is a helper container running e.g. find, capturing the output
to a scratch to be read back (with ref.ReadFile) and parsed.
Signed-off-by: Ian Campbell <ijc@docker.com>
