Feat/telemetry

[mabd-dev]

Pull Request

Description

Send anonymous telemetry usage only if user allows it. When running in CI environment, no consent will be shown, but telemetry can still be disabled with --no-telemetry cli-flag

Changes Made

• added no-telemetry cli-flag
• added no-telemetry to repo config.toml
• save telemetry.json to ${USER_CONFIG_DIR}/reposcan/
• send telemetry warning only once

Testing

• Tested locally with example workflows
• Added new tests (if applicable)
• Tested with different filters, output, etc...

Checklist

• I have starred the repository
• My code follows the project's code style
• I have updated the documentation (README, cli-flags, etc...)
• My changes generate no new warnings
• I have tested my changes in a real workflow
• All tests pass locally

Greptile Summary

This PR introduces opt-in anonymous telemetry via Mixpanel, guarded by a --no-telemetry CLI flag and a telemetry.json consent file stored in the user config directory. A one-time notice is printed on first run; subsequent runs skip the notice.

• New internal/telemetry package: handles UUID generation, consent-file persistence, and analytics dispatch; variables are injected for testability.
• --no-telemetry flag: wired through Config.NoTelemetry, read from both config.toml and CLI flags, and checked in run() before dispatching telemetry.
• CI handling: when the CI env var is set, telemetry is sent immediately without consulting the consent file — bypassing the user-opt-in flow described in the PR.

Confidence Score: 4/5

Safe to merge with one fix: writeTelemetry return values should be checked at both call sites before shipping.

The core telemetry flow works correctly for the happy path. The one concrete defect is that writeTelemetry errors are silently discarded in both getOrCreateTelemetry (UUID persistence) and Send (Warned-state persistence). On any filesystem where the config dir is not writable, every run generates a fresh ephemeral UUID and reprints the consent notice, corrupting analytics data and degrading user experience. The rest of the integration is straightforward and correct.

internal/telemetry/telemetry.go — specifically the two writeTelemetry call sites that drop their error returns.

Important Files Changed

Filename	Overview
internal/telemetry/telemetry.go	New telemetry package — writeTelemetry return values silently discarded in two places, causing UUID and Warned-state loss on write failures.
internal/telemetry/telemetry_test.go	Good breadth of unit tests; test name TestSend_CIEnvironment_PrintsMsgAndSkipsAnalytics contradicts its assertion.
cmd/reposcan/rootCmd.go	Adds no-telemetry flag reading and gates telemetry.Send behind configs.NoTelemetry; logic is correct.
cmd/reposcan/flags_read_test.go	Registers and parses the new no-telemetry flag in tests; assertion only tests the default value.
internal/config/types.go	Adds NoTelemetry bool field with correct TOML tag; no issues.
cmd/reposcan/main.go	Registers --no-telemetry as a BoolP flag; matches pattern of existing flags, no issues.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[run configs] --> B{NoTelemetry?}
    B -- yes --> C[skip telemetry]
    B -- no --> D{CI env set?}
    D -- yes --> E[sendTelemetry directly]
    D -- no --> F[getTelemetryFilePath]
    F --> G{error?}
    G -- yes --> H[log error, return]
    G -- no --> I[getOrCreateTelemetry]
    I --> J{file exists?}
    J -- no --> K[create new UUID + write file]
    J -- yes --> L[read telemetry.json]
    K --> M{Warned?}
    L --> M
    M -- no --> N[print consent notice, set Warned=true, write file]
    M -- yes --> O[skip notice]
    N --> E
    O --> E
    E --> P[analyticsService.Send usage event]

Loading

_{Reviews (4): Last reviewed commit: "send ci to analytics" | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

writeTelemetry error silently discarded — UUID lost on every run

writeTelemetry returns an error, but the return value is ignored here and again at line 65 in Send. If writing the file fails (e.g. a permissions issue on the config dir), no UUID is ever persisted: every subsequent invocation calls getOrCreateTelemetry, finds no file, generates a fresh UUID, fails to write it, and repeats — so all events are sent with different, ephemeral UUIDs, making it impossible to deduplicate users in analytics. Separately, the write at line 65 persisting Warned = true also drops its error, so the consent notice is reprinted on every run whenever the config dir is not writable. Both call sites should check and at least log the returned error.