[developerkunal]

🔧 Changes

Plugin runs, installs, updates and uninstalls are now counted through the existing analytics.Tracker. There is no new tracking client, and AUTH0_CLI_ANALYTICS=false turns these events off like every other event.

What is sent

• CLI - Plugin - Run carries plugin, plugin_version, success and, only when the run failed, error_reason.
• CLI - Plugin - Install, CLI - Plugin - Update and CLI - Plugin - Uninstall carry plugin and plugin_version only.
• Like every event, they also carry the CLI version, OS and architecture, and are sent with the install ID.
• error_reason is one of a fixed list of plugin reason codes, and anything else is sent as other, so free text can never reach an event.

What is never sent. Arguments, flags, tenant names, output and exit codes. The event type has no field for them.

When an event is sent

• A plugin run sends the plugin event instead of the generic CLI - <Plugin> - <Command> - Run event, so tenant, output_format and the command path do not leave the machine for a plugin run.
• A run is only counted once its installed files were verified. A run that fails before that, or only shows help, sends nothing at all.
• Only plugins from the built-in registry are tracked. A plugin from another registry sends nothing.
• Install and update events are sent after the approval is saved and only when something changed. update --all sends one event per updated plugin.
• The uninstall event is sent only after the removal succeeded.
• Nothing is sent when there is no install ID, which is the case in env auth mode.

The "Usage Analytics Disclosure" section in the README now has a short paragraph on what the plugin events carry.

📚 References

DXCDT-2609. Part of the plugin framework stack of 11 PRs, and it builds on the PR below it (DXCDT-2608).

🔬 Testing

The new code is covered by unit tests.

📝 Checklist

• All new/changed/fixed functionality is covered by tests (or N/A)
• I have added documentation for all new/changed functionality (or N/A)