The `defaultPlatform` got on the build system include the variant for arm v6, v7 etc.
This is an important information for us to find the matched platform, but this information
is missed since the code doesn't include variant when assemble the platform information.
And since "V8" variant for arm64 is normalized to an empty string, so we need to take care
of this as well.
Signed-off-by: Dave Chen <dave.chen@arm.com>
Use vertex platform instead of the current system one. This shouldn't break any cache unless qemu was used. Even when qemu was used the issue would not cause any cache collisions because the base images for run were scoped by platform, but better to stop using invalid data for cache key calculation.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
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>
Setting the default `PATH` in the `llb.State` on the client side means it
depends on the `GOOS` of the buildkit client, rather than of the environment
where it will actually execute.
Instead defer this to execution time and insert the default PATH at that point
if one is not present. Doing this in solver/llbsolver/ops/exec covers all
executors and also avoids breaking the cache.
Client compatibility is handled via a new capability.
Fixes#604
Signed-off-by: Ian Campbell <ijc@docker.com>
Tests such as TestNoSnapshotLeak were failing in client mode (e.g. using #522)
because we weren't releasing the intermediate refs.
Resolve this by refactoring the existing code which frees the intermediate refs
from `gatewayFrontend.Solve` into a method on `llbBridgeForwarder` and as well
as the original site also call from the solver when the top-level solve (in
clientside frontend mode) completes. The original call (which is via a defer)
could likely sensibly be moved either earlier or later if desired but leave it
here it is to minimise the scope of the change.
The previous code used the `retErr` named return but the code between that
point and the end of the function already ensured that `lbf.err` is the same as
`retErr`, thus the only change in the code which has moved is
`s/retErr/lbf.err/`. Note that the `res` named return was previously unused by
name.
Fixes#581.
Signed-off-by: Ian Campbell <ijc@docker.com>
Propagate anything in the `frontend.*` namespace from the `frontend.Result`
into the `client.SolveResponse`.
Signed-off-by: Ian Campbell <ijc@docker.com>
This seems wasteful. I think there is no side-effects of the Load+Build of the
definition which would make a difference to the frontend solve.
Note that this changes the presedence of the actual result, previously the
frontend result would overwrite the definition's one, while now the frontend
would not be run.
Signed-off-by: Ian Campbell <ijc@docker.com>
This allows builder code to be written which can be built as either a gateway
container or in a purely client side configuration, giving implementors more
flexibility.
Now when `Solve` sees a request with neither a definition nor a frontend
specified it will make the job available via new LLBBridge endpoints on the
control socket which the client can then use. These end points require the job
id to be present in the gRPC metadata and a client side object is added to
facilitate this.
The `llbBridgeForwarder` type is now exposed as a public `interface
LLBBridgeForwarder` which satisfies the underlying gRPC server interface
(`pb.LLBBridgeServer`) as well as a new `Done()` & `Result()` pair which can be
used to wait for the client to call `Return()` (using a model similar to
`context.Context`).
Signed-off-by: Ian Campbell <ijc@docker.com>
Tibor Vass
Tonis Tiigi
Dave Chen
Akihiro Suda
Ian Campbell
Akihiro Suda
John Howard