Use environment variable for global opt-out and Docker Desktop (if
available) to determine specific experiment states.
In the future, we'll allow per-feature opt-in/opt-out via env vars
as well, but currently there is a single `COMPOSE_EXPERIMENTAL` env
var that can be used to opt-out of all experimental features
independently of Docker Desktop configuration.
When using the Moby/Docker Engine API client, we do not have a
useful user agent value being reported. Ideally, in the future,
the Docker CLI will set this appropriately for plugins when it
initializes the client.
For now, manually set it, which is a bit hacky because it
requires some casting & manually invoking an option function
that's technically meant for initialization. In practice, this
is pretty safe - the cast is checked defensively and we ignore
any errors (which shouldn't be possible anyway).
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
* Move all the initialization code out of `main.go`
* Ensure spans are reported when there's an error with the
command
* Attach the Compose version & active Docker context to the
resource instead of the span
* Name the root CLI span `cli/<cmd>` for clarity and grab
the full subcommand path (e.g. `alpha-viz` instead of just
`viz`)
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
This is a bunch of OTEL initialization code. It's all in
`internal/` because there are re-usable parts here, but Compose
isn't the right spot. Once we've stabilized the interfaces a bit
and the need arises, we can move it to a separate module.
Currently, a single span is produced to wrap the root Compose
command.
Compose will respect the standard OTEL environment variables
as well as OTEL metadata from the Docker context. Both can be
used simultaneously. The latter is intended for local system
integration and is restricted to Unix sockets / named pipes.
None of this is enabled by default. It requires setting the
`COMPOSE_EXPERIMENTAL_OTEL=1` environment variable to
gate it during development.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Integrates PR #9462 with additional fixes/changes.
Additional changes will be required to utilize this.
Co-authored-by: Nicolas De Loof <nicolas.deloof@gmail.com>
Signed-off-by: Ulysses Souza <ulyssessouza@gmail.com>
This also removes the vendoring of the repo
Note that it fixes the problem of double "compose" on calling
the compose plugin with "docker" root flags.
Like in "docker --context default compose version"
Signed-off-by: Ulysses Souza <ulyssessouza@gmail.com>
I noticed this when building the binary; `internal.Version` is set to `v2.0.0-beta.4`,
to match the tag.
```bash
GIT_TAG=v2.0.0-beta.4
make COMPOSE_BINARY=bin/docker-compose -f builder.Makefile compose-plugin \
GOOS=linux \
GOARCH=amd64 \
CGO_ENABLED=0 \
go build \
-trimpath \
-ldflags="-s -w -X github.com/docker/compose-cli/internal.Version=v2.0.0-beta.4" \
-o bin/docker-compose \
./cmd
```
However, the binary has the `v` prefix stripped (which caused a check to fail
when packaging):
```bash
/root/rpmbuild/BUILDROOT/docker-compose-plugin-2.0.0.beta.4-0.fc34.x86_64/usr/libexec/docker/cli-plugins/docker-compose docker-cli-plugin-metadata
++ awk '{ gsub(/[",:]/,"")}; $1 == "Version" { print $2 }'
+ ver=2.0.0-beta.4
+ test 2.0.0-beta.4 = v2.0.0-beta.4
FAIL: docker-compose version (2.0.0-beta.4) did not match
```
This also looks inconsistent with other binaries and plugins we ship:
```bash
docker info --format '{{json .ClientInfo.Plugins}}' | jq .
[
{
"SchemaVersion": "0.1.0",
"Vendor": "Docker Inc.",
"Version": "v0.5.1-docker",
"ShortDescription": "Build with BuildKit",
"Name": "buildx",
"Path": "/usr/libexec/docker/cli-plugins/docker-buildx"
},
{
"SchemaVersion": "0.1.0",
"Vendor": "Docker Inc.",
"Version": "2.0.0-beta.4",
"ShortDescription": "Docker Compose",
"Name": "compose",
"Path": "/usr/libexec/docker/cli-plugins/docker-compose"
},
{
"SchemaVersion": "0.1.0",
"Vendor": "Docker Inc.",
"Version": "v0.8.0",
"ShortDescription": "Docker Scan",
"Name": "scan",
"Path": "/usr/libexec/docker/cli-plugins/docker-scan"
}
]
```
Perhaps there was a specific reason for this, but thought I'd open this PR for
discussion (if the v-prefix should not be there, perhaps we should isntead strip
it when setting the version).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>