Another case: https://findit-for-me.appspot.com/waterfall/build-failure?url=https://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Tests%20(1)/builds/21683

Findit is using try jobs to identify culprit CL that break a build. It will check each revision in the regression range of the first red build until find the culprit.

To speed up the process, we used 'api.chromium_tests.analyze' to get list of targets that are needed to run tests and affected by the revision and to determine if we want to run tests on this revision or skip it.

But lately we found cases where the revision that is the real culprit is skipped by the 'analyze' step.  Do you have any idea why this happen?

Note that https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_chromeos_asan_variable/builds/114/steps/test%20a298aa9c3276b78073a61613787909a0b2427302.analyze/logs/stdio is the suspicious looking analyze results.

I think what's going on in this case is that the files that were modified are all files that get packed into a resource via //chrome/browser/resources:settings_resources, and in this case GN doesn't actually know about the dependencies (since they are indirectly specified through the .grd file).

It's not actually obvious to me what to do about this, except that this is a problem ...

brettw@ any idea about how we could make GN aware of the dependencies in .grd files?

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. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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