Prior to this commit, experimental flags were not distinguishable from
regular flags in `--help`
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Introduce a meter provider to the buildx cli that will send metrics to
the otel-collector included in docker desktop if enabled.
This will send usage metrics to the desktop application but also send
metrics to a user-provided otlp receiver endpoint through the standard
environment variables.
This introduces a single metric which is the cli count for build and
bake along with the command name and a few additional attributes.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This extracts the same logic for parsing annotations from the imagetools
create command, and allows the same flags to be attached to the build
command.
These annotations are then merged into all provided exporters.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This attempts to make it clearer that the --cgroup-parent option is only used
for the containers used during build. Instead of mentioning "build container",
I opted for using "RUN instructions" (to match the --network description),
although this may not be ideal (as it assumes the "Dockerfile" front-end, which
of course may not be the case).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit allows specifying a JSON array to the long-form arg, entrypoint and
envvars.
Non-JSON-array value can still be specified. Buildx treats the value as a JSON
array only when it can be parsed as a JSON array.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
When running `--invoke` against images that have `Cmd` set, the interactions with `Entrypoint` start to cause issues like the following:
/usr/local/bin/bash: /usr/local/bin/bash: cannot execute binary file
Or:
sh: can't open 'bash': No such file or directory
This patch fixes those by explicitly setting `Cmd` to be empty if it is unspecified and `Entrypoint` is being set, which matches `docker`'s behavior:
$ docker image inspect --format '{{ json .Config.Entrypoint }} + {{ json .Config.Cmd }}' bash
["docker-entrypoint.sh"] + ["bash"]
$ docker create --name foo --entrypoint bash bash
$ docker container inspect --format '{{ json .Config.Entrypoint }} + {{ json .Config.Cmd }}' foo
["bash"] + null
$ docker rm foo
$ docker create --name foo bash ls
$ docker container inspect --format '{{ json .Config.Entrypoint }} + {{ json .Config.Cmd }}' foo
["docker-entrypoint.sh"] + ["ls"]
(There are still some weird edge cases in the interaction between the `InvokeConfig` and the original image config, but this fixes the most irritating for me and the rest are going to be deeper changes that are possibly less acceptable. 😅)
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
Container driver wrote manifest digest that had a
mismatch with --iidfile output.
When --iidfile was set the --metadata-file was not
written.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
This was missing, since the driver property can only be fully populated
after loading nodes from disk. So we add logic to load the nodes, and
check for an error, which ensures that the "docker" driver is always
correctly present in the progress description.
Signed-off-by: Justin Chadwell <me@jedevc.com>
--detach shouldn't be the default yet, since it still has the potential
to leak some sessions in odd edge cases, and is slightly more painful to
debug.
For now, we should set the local controller as the default, with the
idea that we can change it back in the future.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This adds an env var which can be used to pass in a path to a file to
read a buildkit source poliy from.
This is applied to any build is executed with the env set.
It is also applied to bakes (which are calling build behind the scenes).
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This will allow result printing to work with the remote controller
(though this currently causes a panic, to be fixed in a follow-up).
Signed-off-by: Justin Chadwell <me@jedevc.com>
logrus info messages aren't particularly in-theme with the rest of the
progress output (and are also frustratingly racy). The progress output
is a lot neater, so we refactor it into that.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Refactor the progress printer creation to the caller-side of the
controller api. Then, instead of passing around status channels (and
progressMode strings), we can simply pass around the higher level
interface progress.Writer.
This has a couple of benefits:
- A simplified interface to the controller
- Allows us to correctly extract warnings out of the controller, so that
they can be displayed correctly from the client side.
Some extra work is required to make sure that we can pass a
progress.Printer into the debug monitor. If we want to keep it
persistent, then we need a way to temporarily suspend output from it,
otherwise it will continue printing as the monitor is prompting for
input from the user, and forwarding output from debug containers.
To handle this, we add two methods to the printer, `Pause` and
`Unpause`. `Pause` acts similarly to `Wait`, closing the printer, and
cleanly shutting down the display - however, the printer does not
terminate, and can later be resumed by a call to `Unpause`. This
provides a neater interface to the caller, instead of needing to
continually reconstruct printers for every single time we want to
produce progress output.
Signed-off-by: Justin Chadwell <me@jedevc.com>
We had some duplicated code between the basic runBuild and
launchControllerAndRunBuild.
This patch refactors out the common logic (since it's only really like
to keep growing), and has runBuild call into either the controller or
directly start the build depending on whether BUILDX_EXPERIMENTAL is
set.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This ensures that the code used to capture and evaluated a result is
only executed when built through the controller. Otherwise, no build
result should be recorded.
This ensures that new code added to capture and store the build result
for debugging isn't used when BUILDX_EXPERIMENTAL is not set.
Signed-off-by: Justin Chadwell <me@jedevc.com>
In 566f41b598, we added a check to ensure
that we avoid resolving http URLs for Dockerfile. However, we have
another circumstance we should not resolve the path in - if the context
is a remote context, the dockerfile is resolved in that context (see
build.go#LoadInputs for more information).
Therefore, we should only resolve the dockerfile to a local directory if
the context is also resolved to a local directory.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Dockerfiles can be HTTP URLs as well as local paths 🤦
We just copy the same logic we use for resolving context paths, and
apply it here as well.
Signed-off-by: Justin Chadwell <me@jedevc.com>
BuildKit's gitutil package behaves slightly differently than moby's
urlutil, so we should rely on BuildKit's gitutil when detecting URLs to
avoid cases of accidentally producing invalid build requests that can
confuse users.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This allows the build package code to become more generic, and also
ensures that when the environment variables are not propogated (in the
case of the remote controller), that we can still correctly set
SOURCE_DATE_EPOCH.
Signed-off-by: Justin Chadwell <me@jedevc.com>
We can perform all attestation processing, handling how the sbom and
provenance arguments interact on the client, while applying defaults on
the server.
Additionally, this allows us to start pulling fields out of CommonOpts.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Now clients can access the result of the solve, specifically the image
id output. This is a useful refactor, as well as being required if we
want to allow bake to invoke through the controller api.
This also allows us to remove the quiet option from the API, since we
can compute the required progress type outside of the controller, and
can print the image id from the result of the solve.
As a follow-up, we should also be able to remove the image id file
output from the controller api, now that the client has access to it.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Strongly typing the API allows us to perform all command line parsing
fully on the client-side, where we have access to the client local
directory and all the client environment variables, which may not be
available on the remote server.
Additionally, the controller api starts to look a lot like
build.Options, so at some point in the future there may be an
oppportunity to merge the two, which would allow both build and bake to
execute through the controller, instead of needing to maintain multiple
code paths.
Signed-off-by: Justin Chadwell <me@jedevc.com>
We don't know if other builds might be running, etc, so we should allow
the server to decide when to exit.
Signed-off-by: Justin Chadwell <me@jedevc.com>
The NewPrinter function is mostly borrowed from buildkit. However, at
some point, it seems that the implementations drifted.
This patch updates buildx to be more similar in behavior to it's
buildkit counterpart, specifically, it will explicitly fail if a TTY
output is requested using "--progress=tty", but the output is not
available.
To gracefully fallback to plain progress in this scenario,
"--progress=plain" is required.
Signed-off-by: Justin Chadwell <me@jedevc.com>
We should be able to detect nolint comments that point to linters that
are disabled (such as with the removed structcheck).
Signed-off-by: Justin Chadwell <me@jedevc.com>
If user does not specify image certain container parameters, we can load
them from the exporter metadata.
Additionally, we introduce a new "default" value for the --invoke flag,
that keeps all of the default parameters (since cobra does not have an
easy way of accepting an optional flag argument).
Signed-off-by: Justin Chadwell <me@jedevc.com>
Append an [experimental] tag to the end of each experimental command to
highlight that these are experimental options. Square brackets are used
instead of parentheses as parentheses are already in use to highlight
examples and defaults.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Print flag can be used to make additional information
requests about the build and print their results.
Currently Dockerfile supports: outline, targets, subrequests.describe
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Laura Brehm