Add the service instance id to the resource attributes to prevent
downstream OTEL processors and exporters from thinking that the CLI
invocations are a single process that keeps restarting. The unique id
can be removed through downstream aggregation to prevent cardinality
issues, but we need some way to tell OTEL that it shouldn't reset the
counters.
Move the check for the experimental flag to its own package and then use
that invocation to prevent creating exporters so metrics are disabled
completely. This makes it so we don't have to check for the experimental
flag in every place we add metrics until we decide to make metrics
stable in general.
This also moves the OTEL initialization to a `util/metricutil` package
to be more consistent with the existing util naming and to differentiate
it from the upstream `metric` name. Using both `metrics` and `metric` as
import names was confusing since `metric` was an upstream dependency and
`metrics` was a local utility. `metricutil` matches with the existing
utilities and makes clear that it isn't a spelling mistake.
The record version metric has been removed since we weren't planning on
keeping that metric anyway and most of the information is now included
in the instrumentation library name and version. That function is
included as a utility in the `otel/sdk/metric` package to retrieve the
appropriate meter from the meter provider.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
See https://github.com/docker/cli/pull/4599 and
https://github.com/docker/cli/pull/4769.
Since we switched to using the cobra command context instead of
`appcontext`, we need to set up the signal handling that was being
provided by `appcontext`, as well as configuring the context with
the OTEL tracing utilities also used by `appcontext`.
This commit introduces `cobrautil.ConfigureContext` which implements
the pre-existing signal handling logic from `appcontext` and cancels
the command's context when a signal is received, as well as doing
the relevant OTEL config.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
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 adds the ability to source additional local build definition files when
sourcing Bake files via a remote url.
Prefixing a file with 'cwd://' will source a bake file on the local
machine, instead of the remote location.
Local files will be read/have precedence before remote files.
Usage:
```
docker buildx bake https://github.com/example/upstream.git --file cwd://docker-bake.override.hcl --print
```
This will source a default file from the example/upstream repository,
and also source a build definition from the local machine.
Also moves remote and local files reading logic to a func
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
Signed-off-by: Cameron Adams <pnzreba@gmail.com>
Co-authored-by: CrazyMax <crazy-max@users.noreply.github.com>
ReadLocalFiles should allow passing the stdin file as an argument, which
allows us to read from dockerCli.Stdin() to be consistent with other
commands in the same package.
Signed-off-by: Justin Chadwell <me@jedevc.com>
Previously, when directly modifying the args map when reading targets,
we could end up in a scenario where bake tests that compare arg maps
would fail if SOURCE_DATE_EPOCH was set in the environment.
This patch prevents this failure by setting the SOURCE_DATE_EPOCH at the
command level (which isn't injected into tests as well), ensuring that
we test correctly even when SOURCE_DATE_EPOCH is set in the environment.
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>
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>
Groups that contained other groups were not recursively resolved by
ReadTargets, which prevented output from --print from being useable as a
self-contained bake file.
This patch ensures that all groups that are referenced inside the bake
file are actually defined under the groups field. This has required a
substantial refactor, as previously only a single group was returned
from ReadTargets, notably, returning a map of groups, instead of a
slice.
This does introduce a small behavior change to the behavior of --print -
while previously, passing a group name to bake would return all the
targets of that group back as the default group, now only the name of
that group will be inserted into the default group, keeping the original
group intact. The impact of this can be observed in some of the changes
to the bake_test.go file.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This allows all subcommands to use this flag.
Additionally reads the default value for the flag from the
`BUILDX_BUILDER` env var.
Precedence is:
CLI ARG > flag > env var > config file
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Although bake is for running multiple targets, --set required a single
target name for overriding a property. This change allows matching
multiple targets for overrides.
Signed-off-by: Tibor Vass <tibor@docker.com>
Tested with `kind` and GKE.
Note: "nodes" shown in `docker buildx ls` are unrelated to Kubernetes "nodes".
Probably buildx should come up with an alternative term.
Usage:
$ kind create cluster
$ export KUBECONFIG="$(kind get kubeconfig-path --name="kind")"
$ docker buildx create --driver kubernetes --driver-opt replicas=3 --use
$ docker buildx build -t foo --load .
`--load` loads the image into the local Docker.
Driver opts:
- `image=IMAGE` - Sets the container image to be used for running buildkit.
- `namespace=NS` - Sets the Kubernetes namespace. Defaults to the current namespace.
- `replicas=N` - Sets the number of `Pod` replicas. Defaults to 1.
- `rootless=(true|false)` - Run the container as a non-root user without `securityContext.privileged`. Defaults to false.
- `loadbalance=(sticky|random)` - Load-balancing strategy. If set to "sticky", the pod is chosen using the hash of the context path. Defaults to "sticky"
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
CrazyMax