Phil has already been working on a system like this.

The best/easiest solution is to integrate ts_mon and/or event_mon into depot_tools, and then provide wrapper binaries for the things we want to track.

The biggest concern is obviously collecting user data. The system would have to
a) Not run on bots (or run differently on bots, so we can differentiate their usage)
b) Not run on non-Googler machines (at least without an explicit opt-in)

I'm 90% sure there's a bug for this to be duped in to, but I'll let Phil find that and dupe it if appropriate.

I think chrishall@ was looking into this as well, maybe in conjunction with philwright@?

chrishall, philwright, are there any plans to work on something like this?

Ping - I was wondering about this today, and curious if Chris or Phil or anyone had any thoughts in the past few months about tracking command-line tool usage...

For what I was thinking of tracking (# uses of webkit-patch rebaseline-cl), opt-in reporting or limiting to Googler workstations would be OK.

The current plan is: add limited call-home functionality (command line, scrubbed environment, current git repo if any) to python_runner[1] which is the single entry point for the vast majority of our tools (in particular, git-cl, all our other git extensions, and gclient). Only enable the functionality if the hostname ends in ".corp.google.com". This will provide pareto-style coverage: 80% of the results for 20% of the effort.

This requires getting basically three things right:
* The format for tracking usage. Maybe this is event_mon. Maybe this is gRPC or JSON to a one-shot appengine app. Maybe it's something else entirely.
* The integration point. At first blush, this should be python_runner, since it is a single point of entry for the vast majority of the executables in depot_tools. But it is a shell script, which makes it limited, so some additional development might be necessary.
* The limits on collection. We definitely should not collect from non-Google-employees without their explicit opt-in consent. Starting with a simple judgement based on hostname is simple and unlikely to be wrong, and better heuristics could be used later.

We just need someone to actually have the time to put in the effort. Maybe that'll be me during our december production freeze. Maybe it'll be chrishall@. Maybe it'll be someone with some 20% time.

[1] https://chromium.googlesource.com/chromium/tools/depot_tools/+/master/python_runner.sh

+katthomas

This has come up again in multiple discussions lately.  Has any of this changed since the update here in November?

I'd like to get this on Q3 OKRs for someone

event_mon seems like a good choice for this. If someone is interested in implementing, they could do it now. Happy to talk to that person. :)

Excuse me, not event_mon exactly since we're transitioning away from that... but treating this as event data and sending it to big_query for visualization/analysis.

If we do this synchronously, it will slow down the tools slightly because of the network call. That could be annoying. I don't have a plan to implement something asynchronous for Python, but it could use whatever we currently use for Buildbot (which I'll be modifying for BQ). But, that might be kind of heavyweight, and I'd prefer it didn't stay around after Buildbot goes away.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot