5 ms·

> you're going to have to opt out of a lot more than this one setting The opt-out situation for gh CLI telemetry is actually trickier than it sounds. gh runs i

> you're going to have to opt out of a lot more than this one setting The opt-out situation for gh CLI telemetry is actually trickier than it sounds. gh runs in CI/CD pipelines and server environments where you may not want any outbound connections to github.com at all, not because of privacy but because of networking constraints. In those environments, the telemetry being on by default means your CI fails or your Bastion host can't reach GitHub at all. Compare this to git itself, which is entirely local until you explicitly push. The trust model is different: git will never phone home unless you configure it to. gh, being a wrapper around the GitHub API, has to make those calls to function - but that's separate from whether it should also be collecting and uploading your command patterns.

hahn-kev 5mo ago
Isn't the gh CLI useless if it can't connect to GitHub.com? Or does it work with enterprise GitHub and that's the use case you're talking about.
- pledg 5mo ago
  It does work with enterprise instances
tensegrist 5mo ago
> In those environments, the telemetry being on by default means your CI fails or your Bastion host can't reach GitHub at all. i'd be surprised if the inability to submit telemetry is a hard error that crashes the program
- rtpg 5mo ago
  There are definitely slightly annoying variants of this of "ah the program does its job in 200ms but takes 5s to shutdown timing out trying to send telemetry data". Especially annoying on CLI programs. I have been unpleasantly surprised by several programs outright crashing when not being able to send telemetry data consistently. Though this has usually been when the connection is a bit odd and it is able to send through _some_ stuff but then crashes when it fails later.
  - kippinsula 5mo ago
    ran into this flavor once with a different tool, not gh. our deploy job was consistently about 8s longer than it should've been, turned out a fire-and-forget telemetry POST wasn't actually fire-and-forget when the endpoint got slow. NO_PROXY plus blackholing the host fixed it, but probably the kind of thing you shouldn't have to find via flame graph.

hahn-kev 5mo ago

Isn't the gh CLI useless if it can't connect to GitHub.com? Or does it work with enterprise GitHub and that's the use case you're talking about.

pledg 5mo ago
It does work with enterprise instances

tensegrist 5mo ago

> In those environments, the telemetry being on by default means your CI fails or your Bastion host can't reach GitHub at all. i'd be surprised if the inability to submit telemetry is a hard error that crashes the program

rtpg 5mo ago
There are definitely slightly annoying variants of this of "ah the program does its job in 200ms but takes 5s to shutdown timing out trying to send telemetry data". Especially annoying on CLI programs. I have been unpleasantly surprised by several programs outright crashing when not being able to send telemetry data consistently. Though this has usually been when the connection is a bit odd and it is able to send through _some_ stuff but then crashes when it fails later.
- kippinsula 5mo ago
  ran into this flavor once with a different tool, not gh. our deploy job was consistently about 8s longer than it should've been, turned out a fire-and-forget telemetry POST wasn't actually fire-and-forget when the endpoint got slow. NO_PROXY plus blackholing the host fixed it, but probably the kind of thing you shouldn't have to find via flame graph.