Currently, "usage" reports are sent, which are aggregated.
Add "event" variant, which won't be aggregated.
For compatibility, the "usage" events remain and nothing has
changed in terms of how they parse the command args, for example.
This will ensure continued functioning of anything that relies
on these metrics.
For the "event" variants, the CLI parsing is slightly different
in an attempt to improve data analysis capabilities while still
being respectful of user privacy (i.e. only known values of Docker
CLI commands/flags are ever recorded). Additionally, execution
duration information is now reported with these events.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Add a timer around command invocations to be reported with metrics.
This isn't actually sent anywhere currently, as it's meant for
evented data which is forthcoming. (We could report it with the
current events, but it's not clear that there's any value in doing
so.)
The signature for `Track()` has been changed to take an object with
all the fields. This is both for sanity to keep the method from
getting ridiculously long, and to make it easier to unify the usage
(heartbeat) and event code paths by ensuring we have all the data
for both.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Compose doesn't actually currently use this code, it's only used
here. Moving it inline so that we can drop it from Compose in the
future or make changes as needed without worrying about this as a
dependency.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Refactor the metrics client slightly to add the concept of a
"reporter" that actually sends the metrics.
The primary implementation is HTTP-based as before, but a key
difference now is that there's another variant that writes to
a file for simplified debugging. This is activated by setting
the `DOCKER_METRICS_DEBUG_LOG` environment variable to a file
path to write events to as JSON lines.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
The command now was showing 2 informational messages (about PAT and
Scan); the scan one had been there for a while so most users will
know about it by now.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
1. Use path from env variable `$DOCKER_COM_DOCKER_CLI`
2. Use path formed from parent directory of current process joined with
`com.docker.cli`
3. Look for `com.docker.cli` on $PATH
Signed-off-by: Nick Sieger <nick@nicksieger.com>
DD relies on having the CLI socket available in /var/run when running in
WSL. So in case we can't find the CLI socket in the calling user's home
directory, fall back to /var/run.
Signed-off-by: Piotr Stankiewicz <piotr.stankiewicz@docker.com>
We should not rely on having a global path for the Docker CLI socket. On
macOS this forces Docker Desktop to access directories which require
raised privileges. Whereas on Linux we do not create sockets in that
location at all, currently. So look for the Docker CLI socket in the
User's home directory.
Signed-off-by: Piotr Stankiewicz <piotr.stankiewicz@docker.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>
