The `docker scout quickview` hint, displayed
after a user pulls or builds an image, only
works if the user is logged in to Hub.
Check if user isn't logged in, and make hint
more explicit in this case.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
To avoid any conflict with the CLI, use the `plugins` section of the
config. This section is read and saved by the CLI without the risk to
remove the value in there. So it's a safe way to deal with this feature.
As it's a cross plugin configuration (now for scout but goal is wider
than that) then put it under a generic `-x-cli-hints` name so that other
plugins might use it if needed.
Value can be true/false, but is parsed against these exact two values
instead of using the ParseBool.
Both the environment variable and the config value are parsed the same
way.
Signed-off-by: Yves Brissaud <yves.brissaud@docker.com>
- cliHints entry in config.json
- if not present, enabled by default
- can be overridden by the DOCKER_CLI_HINTS environment variable
Signed-off-by: Yves Brissaud <yves.brissaud@docker.com>
On `docker build` and `docker pull` commands, display a hint to
`docker scout quickview`.
Hints are disabled if quiet flag is used or if `DOCKER_SCOUT_HINTS`
environment variable is set to a false (according to Go) value:
`0`, `f`, `F`, `false`, `FALSE`, `False`
In case of a `docker build` the `docker scout quickview` command doesn't
need an argument as it will take the most recently built image by
default.
In case of a `docker pull` the pulled image is extracted from the
command arguments.
Signed-off-by: Yves Brissaud <yves.brissaud@docker.com>
* for per-invocation events, only look at Compose `alpha`
commands
* for aggregated events, include Compose `alpha` commands
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
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>
