Blink>ToolsTest renamed to Blink>Infra

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/41a56ae7ec64f52162ccd7a63f9f55596b84fae3

commit 41a56ae7ec64f52162ccd7a63f9f55596b84fae3
Author: nainar <nainar@chromium.org>
Date: Thu May 12 08:27:33 2016

Add ability to create CSV of Stale Test Expectations with list of all bugs and filenames

This patch allows us to create a CSV of stale TestExpectations with
list of all bugs and filenames. A TestExpectations entry is considered
stale if the bug associated with it has not been updated in 90 days.

This patch also adds a fix to make sure you are taking user input into
consideration when checking how stale a bug is.

The design doc for this is here: https://drive.google.com/open?id=1oH67jAzE70-59JLoJ9r0NG--Ew7KL3Qtdh52D0Ogj7k

BUG=597797

Review-Url: https://codereview.chromium.org/1949353002
Cr-Commit-Position: refs/heads/master@{#393208}

[modify] https://crrev.com/41a56ae7ec64f52162ccd7a63f9f55596b84fae3/third_party/WebKit/Tools/Scripts/print-stale-test-expectations-entries

Just ran print-stale-test-expectations-entries, and I think there are a couple things that will make it easier to use or more helpful:

 - Add days since last comment in the CSV
 - Add whether or not the bug is closed in the CSV

Also, believe that it may be getting incorrect results because it's making requests to projecthosting instead of monorail, so I think it may not be taking into account activity on bugs since the monorail migration.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/420dc135ca4155874320b02ef6e1ba3314e168dd

commit 420dc135ca4155874320b02ef6e1ba3314e168dd
Author: qyearsley <qyearsley@chromium.org>
Date: Mon Jul 11 17:05:13 2016

In print-stale-test-expectations-entries, avoid repeating the same request.

When running print-stale-test-expectations-entries, I noticed that it makes a request for each line even if it already checked whether a particular bug is stale; this change would speed up print-stale-test-expectations-entries by saving the results of the request about the state of the bug.

BUG=597797

Review-Url: https://codereview.chromium.org/2131463005
Cr-Commit-Position: refs/heads/master@{#404680}

[modify] https://crrev.com/420dc135ca4155874320b02ef6e1ba3314e168dd/third_party/WebKit/Tools/Scripts/print-stale-test-expectations-entries

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/75c5d0912c9c8052ec04aa66a056f346394e8abe

commit 75c5d0912c9c8052ec04aa66a056f346394e8abe
Author: qyearsley <qyearsley@chromium.org>
Date: Mon Jul 11 19:22:32 2016

Refactor print-stale-test-expectations-entries.

In this CL:

 - Extract a function check_expectations_line
 - Extract a function write_csv
 - Remove unused imports
 - Print errors to stderr and include bug links in message

BUG=597797

Review-Url: https://codereview.chromium.org/2130823002
Cr-Commit-Position: refs/heads/master@{#404707}

[modify] https://crrev.com/75c5d0912c9c8052ec04aa66a056f346394e8abe/third_party/WebKit/Tools/Scripts/print-stale-test-expectations-entries

@qyearsley:

Yup the info being generated currently is incorrect. I have reached out agable who directed me to the Monorail API. Should have a patch up for it as soon as my client ID, etc are whitelisted. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c3e861ceca16f92cf5eb0f889d208175bc971d3b

commit c3e861ceca16f92cf5eb0f889d208175bc971d3b
Author: nainar <nainar@chromium.org>
Date: Tue Aug 23 04:29:55 2016

Add more informtion to the CSV generated

Add CSV row headers, days since last comment and whether or not bug is closed and owner to the CSV

BUG=597797

Review-Url: https://codereview.chromium.org/2256773004
Cr-Commit-Position: refs/heads/master@{#413664}

[modify] https://crrev.com/c3e861ceca16f92cf5eb0f889d208175bc971d3b/third_party/WebKit/Tools/Scripts/print-stale-test-expectations-entries

I have not worked on this in ages. I am ashamed to say. Adding myself back to Sheriff queue since I can't dedicate times to do Infra work

No problem.

In any case, the next step here is to get the script to talk to Monorail.

jrobbins@, quick question: if we want to make a script (https://cs.chromium.org/chromium/src/third_party/WebKit/Tools/Scripts/print-stale-test-expectations-entries) fetch basic information about issues given issue IDs (last update date, status, maybe reporter/owner), what should we do with regards to credentials or client ID?

Is there an easy way to fetch some basic information without any private credentials, or would it be best to try to get the monorail credentials of the user running the script? Can you point us towards any examples

You need to get a client ID whitelisted.  Details are in this doc:
https://docs.google.com/document/d/1SLK0AYokyaIGG_riOgQJ9UUMXhC58kqmj8l4vZT42vM/edit#heading=h.viii59spgqww

We don't allow anonymous API access (at least not in our current v1 API) because of DoS concerns.

In this case, there's no particular Google Cloud Platform project associated with this script; it's an independent script expected to be run directly by users, who are expected to be Chromium project members.

Do you think in this case it makes sense to use do re-use the service account and code in depot_tools (e.g. https://cs.chromium.org/chromium/tools/depot_tools/my_activity.py?l=460, which will either use cached credentials from ~/.depot_tools_oauth2_tokens or prompt the user to run `depot-tools-auth login bugs.chromium.org`)?

This is a subset of a problem robertma@ and I have discussed in the context of LayoutTests/external/wpt. What I'd like is a quick and easy way to list for a directory all the things that aren't plainly expected to pass, i.e. any entries in TestExpectations or other expectation files or the existence of *-expected.txt for testharness.js tests.

I think this isn't just about understanding the current state of tests not plainly expected to pass it's also about being able to remove tests that aren't providing value (e.g. tests that are expected-flaky for a very long time) in order to improve long-term maintainability.

qyearsley@, is it still true that "Tests that have been skipped on all platforms for >3 months get deleted"?

Nope, it was never true, that was just a proposal.

Should this be downgraded to P3 given that it doesn't seem to be actively worked on?

Downgrading to P3