For most CLs, we try to limit what targets get compiled and what tests get run to only those affected by the change in question. For changes that touch DEPS however, we skip that analyze logic and instead run *all* the things:
https://chromium.googlesource.com/chromium/src/+/master/testing/buildbot/trybot_analyze_config.json#25

Consider all the autorollers that are continuously updating pins in chromium:
https://chromium.googlesource.com/chromium/src/+log/master/DEPS

Each one of those updates is (at the very least) one entire CQ run. Given that we're consistently running into capacity problems on the CQ (goma & test & even builder pool), I wonder how much unneeded drain on our resources these rolls are.

Gclient has a "diff" command that will theoretically provide the list of files changed in a sub-repo during a DEPS-roll. We could pass this list onto our analyze logic and remove the exclusion of DEPS (at least for rolls... any change to hooks will likely have to stay as exclusions). That way, DEPS rolls build and test only the targets that it would affect.

First I gotta get a good feel for how much of a drain deps rolls are on our capacity. Might have to plug into  gerrit's rest API for the full list of roll patches, since it doesn't appear possible to correlate the contents of a change with our CQ/buildbucket/swarming tables.