[jsternberg]

Use the docker/cli library provided tracer rather than create and manage
our own. This has the benefit of less code and it puts the correct setup
of the docker telemetry tracer into the same one the core cli and buildx
use.

This also allows compose to use the same debug environment variables
that the cli and buildx use for testing telemetry.

This relies on docker/cli#7433 to work properly since
the current docker/cli library doesn't currently correctly shut down the
tracer and meter provider.

[docker-agent]

Assessment: 🔴 CRITICAL

Two confirmed issues introduced by this PR:

1. [high/security] go.mod:144 — The replace directive redirects github.com/docker/cli to a personal fork (jsternberg/cli) outside Docker's control. This must not be merged.
2. [medium] internal/tracing/tracing.go:56 — InitProvider now returns a no-op shutdown, causing buffered OTLP spans to be silently dropped on process exit (regression from prior behavior; the PR description acknowledges the upstream fix is not yet shipped).

[docker-agent]

[high/security] replace directive pins docker/cli to an unmerged personal fork

The added line substitutes the official github.com/docker/cli module with the PR author's personal fork (github.com/jsternberg/cli) on a pseudo-version commit that is outside Docker's control:

replace github.com/docker/cli => github.com/jsternberg/cli v25.0.1-0.20261023181239-bcd15ee400ad+incompatible

While the full 12-hex commit suffix pins exact bytes (integrity), the fork lives on a personal GitHub account — it can be deleted, the account can be compromised, or the pseudo-version can be yanked — any of which breaks builds or introduces malicious code for every downstream consumer of docker/compose.

The PR description acknowledges this as a temporary workaround pending docker/cli#7433. This replace directive must not be merged into main; it should be removed once the upstream fix is published as a proper release from the official docker/cli repository.

Confidence	Score
🟢 strong	100/100

[docker-agent]

[medium] InitProvider returns a no-op shutdown — buffered OTLP spans will be dropped on exit

The old implementation returned tracerProvider.Shutdown, which flushed buffered spans to the OTLP exporter before the process exited. The new implementation returns a no-op:

func InitProvider(dockerCli command.Cli) (ShutdownFunc, error) {
    return func(ctx context.Context) error {
        return nil
    }, nil
}

wrapRunE in cmd/cmdtrace/cmd_span.go still calls tracingShutdown with a 100 ms timeout, but since tracingShutdown is now a no-op that call does nothing. The PR description explicitly states that "the current docker/cli library doesn't correctly shut down the tracer and meter provider yet" (pending docker/cli#7433), so the docker/cli side also does not flush.

The net effect is a regression in observability: any spans buffered in the TracerProvider after a compose command completes will be silently dropped rather than exported to the collector. This was working correctly before this PR.

Consider either: (a) keeping a local tracerProvider.Shutdown call until the upstream fix ships, or (b) documenting this as a known temporary limitation with a // TODO(jsternberg): remove once docker/cli#7433 is merged comment so it is not overlooked.

Confidence	Score
🟢 strong	100/100

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[ndeloof]

Need to wait for a docker/cli release before we can merge this one