feat: support enum flags in telemetry to log known flag values
- Dominant language
- Go
- Stars
- 569
- Forks
- 364
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 136
Description
## Summary
Add support for "enum flags" at the cobra layer so that known flag values (not just flag names) are automatically logged in `cmd.flags` telemetry. This would eliminate the need for separate command-specific telemetry attributes for flags with known value sets.
## Background
Currently, `cmd.flags` in `cli/azd/cmd/middleware/telemetry.go` only records **flag names** that were explicitly set by the user, not their values. For flags like `--provider` (github/azdo) and `--auth-type` (federated/client-credentials), separate telemetry attributes (`PipelineProviderKey`, `PipelineAuthKey`) are needed to capture the resolved values.
@weikanglim [suggested in PR #7299](https://github.com/Azure/azure-dev/pull/7299#discussion_r2988870291) that we define enum flags at the cobra layer and allow known values to be logged directly, reducing duplication.
## Proposed Approach
1. **Add enum annotations to flag definitions** — Commands with enum-like flags (e.g., `--provider github|azdo`, `--auth-type federated|client-credentials`) would annotate the flag with its known values
2. **Update telemetry middleware** — `cmd/middleware/telemetry.go` would check for enum annotations and log the value (not just the name) for annotated flags
3. **Remove duplicate attributes** — Once enum values flow through `cmd.flags`, remove the separate `PipelineProviderKey`, `PipelineAuthKey`, etc.
## Scope
### Files likely affected (6-12):
- `cli/azd/cmd/middleware/telemetry.go` — core change
- `cli/azd/cmd/pipeline.go` — `--provider`, `--auth-type`
- `cli/azd/cmd/auth_login.go` — `--federated-credential-provider`
- `cli/azd/cmd/copilot.go` — `--scope`, `--action`, `--operation`, `--permission`
- `cli/azd/cmd/extension.go` — `extension source add --type`
- `cli/azd/cmd/templates.go` — `template source add --type`
- Related tests
### Precedent
`cli/azd/pkg/output/parameter.go` already uses flag annotations for output formats — a similar pattern could be extended.
### Considerations
- Changing `cmd.flags` to include values has **downstream cardinality implications** for telemetry pipelines and Kusto queries
- Need to ensure only known/enum values are logged (not arbitrary user input) to avoid PII concerns
- Runtime-resolved values (e.g., auto-detected provider) may still need separate attributes since they're not flag values
## Related
- PR #7299 — Metrics audit (where this was identified)
Contributor guide
Assessment
This issue has not been assessed yet.