The PATH is very critical during container runs on
Windows. Windows stores the PATH details in its
registry hive, while in unix, this is often
stored in the image's config. See further details
at #5445
Setting a default path like we do on Linux
(which is mostly not used since the PATH is
already set in the configs), works against
the expected build experience, especially when
it comes to installers and commands like `setx`.
Therefore, we skip setting the default PATH on
Windows, and leave it for the OS to load it
from its registry hive.
This also further supports backward compatibilitiy
with the current experience with docker classic
builder.
Users wishing to explicitly store this in the
configs can opt-in by using the ENV PATH= ..
in the Dockerfile, etc.
See also the same practices on Docker Engine
and Containerd:
- da3b31fb2c/oci/defaults.go (L24-L33)
- 041743e8af/pkg/oci/spec_opts_windows.go (L66-L69)closes#5445
Signed-off-by: Anthony Nandaa <profnandaa@gmail.com>
Calling marshal changes the internal state of the op, for example
addCap() helper adds capability constraints. These can race with
same map being read by another Marshal call. Locking the Marshal
function itself also makes sure that the cache is not recomputed
in this case.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
vtproto is an extra protobuf compiler that generates special methods
suffixed with `VT` that create typed and unrolled marshal and unmarshal
functions similar to gogo that can be used for performance sensitive
code. These extensions are optional for code to use but buildkit uses
them.
A codec is also included to utilize vtproto for grpc code. If the
package `github.com/moby/buildkit/util/grpcutil/encoding/proto` is
imported then vtproto will be used if it exists and otherwise it will
use the standard marshaling and unmarshaling methods.
This codec has an important difference from the default codec. The
default codec will always reset messages before unmarshaling. In most
cases, this is unnecessary and is only relevant for `RecvMsg` on
streams. In most cases, if we are passing in an existing message to this
method, we want to reuse the buffers. This codec will always merge the
message when unmarshaling instead of resetting the input message.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This fixes a problem with the new protobuf marshaling with the standard
library. LLB digests are now forced into deterministic marshaling to
ensure they produce the same digest when marshaled multiple times.
In addition, the marshal cache has also been fixed to work in
multi-threaded frontends with multiple different constraints.
Previously, if an LLB vertex was used in multiple goroutines and
marshaled concurrently, the cache would be broken. This could cause
certain problems when a specific node was used multiple times in the
same LLB tree.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Remove gogoproto in favor of the standard protobuf compiler. This
removes any nonstandard extensions that were part of gogoproto such as
the custom types.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This adds the syntax to Dockerfile frontend.
I purposedly chose to use a simple format for this as it's likely going
to be debated. As implemented, the following format is supported:
```
RUN --mount=type=secret,id=MYSECRET,env
```
or, more explicitly:
```
RUN --mount=type=secret,id=MYSECRET,env=true
```
will mount the secret with id MYSECRET as a new environment variable with the same name.
Using 'target', it's possible to create a different environment
variable:
```
RUN --mount=type=secret,id=mysecret,target=MY_SECRET,env
```
will mount 'mysecret' secret as MY_SECRET environment variable.
Any suggestions on making it more ergonomic are welcome.
Signed-off-by: a-palchikov <deemok@gmail.com>
This allows LLB-directed content-based cache enablement for each mount.
Some mounts may not be explicitly unabled (because it would be unsafe) -
for these cases we explicitly error out.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This is just a first round of "would have been useful to me" sort of
documentation and examples for the LLB client API.
This is not in any way exhaustive.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This allows a frontend to request a specific for stubs removal.
By default, if not specified, this will revert to the previous
behaviour. New gateway clients however will set the property to the
desired recursive removal mode.
This property needs to be set for both components that call the
executor: for ExecOp, as well as for the StartContainer API.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Relates to a82fff6377/docs/packages.md (proxies)
> (..) the first four of these are the standard built-in build-arg options
> available for `docker build`
> (..) The last, `all_proxy`, is a standard var used for socks proxying. Since
> it is not built into `docker build`, if you want to use it, you will need to
> add the following line to the dockerfile:
>
> ARG all_proxy
Given the we support all other commonly known proxy env-vars by default, it makes
sense to add this one as well.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
