Was there a "METRICS COLLECTION" warning that you didn't include in your `git cl issue` output?

I ran into this a few days ago after `gclient sync` (which gave me the new depot_tools with metrics collection). There was a warning for the first 10 depot_tools invocations (including `git cl`), and apparently blinkpy doesn't filter the output properly. The issue went away after I called `git cl` 10 times.

Ah.... Yes. It is there. Really? Really!

Good point Robert --

So using git cl issue and grabbing the number from the output is pretty brittle; so one possible action item here might be to change the way that rebaseline-cl gets the issue number.

Quinten, do you have anything more reliable in mind?

I just ran into this myself and applied the hack

diff --git a/third_party/blink/tools/blinkpy/common/net/git_cl.py b/third_party/blink/tools/blinkpy/common/net/git_cl.py
index 887a4cecf57c..a0aa523a88be 100644
--- a/third_party/blink/tools/blinkpy/common/net/git_cl.py
+++ b/third_party/blink/tools/blinkpy/common/net/git_cl.py
@@ -87,7 +87,8 @@ class GitCL(object):
         return builders_by_bucket
 
     def get_issue_number(self):
-        return self.run(['issue']).split()[2]
+        output = self.run(['issue']).split()
+        return output[output.index('number:')+1]
 
     def _get_cl_status(self):
         return self.run(['status', '--field=status']).strip()

which at least allows the script to do its thing in the happy path. The existing code is returning '*' because the metrics collection warning actually comes first in the self.run call's return value. It would be nice to have a better way to do this (or even allow the user to just pass in the issue number), but this at least allows things to work for the moment.

Thanks bungeman. Something like that might prevent someone else from hitting this in the next week. Uploaded https://chromium-review.googlesource.com/c/chromium/src/+/1156994.

In terms of what I had in mind, I was thinking that instead of parsing output of `git cl issue` we could potentially just do whatever `git cl issue` is doing; the actual source of truth is in the local git config for the repo.

I think what git cl issue is doing to get the issue number (when not explicitly specified) is essentially

$ git config --local branch.$(git symbolic-ref --short -q HEAD).gerritissue

note that 'git cl' takes an '-i' or '--issue' param so it's possible to write explicitly specify the issue number and do silly things like

$ git cl -- issue 123  issue
> Issue number: 123 (https://chromium-review.googlesource.com/123)

(which unfortunately will set the issue number as well). It would be nice if the issue could be specified directly like this to blink_tool.py (but without the unfortunate magic issue setting).

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

commit 027d7020987d56b135c21eb26235f3004c4a70b9
Author: Quinten Yearsley <qyearsley@chromium.org>
Date: Tue Jul 31 20:52:25 2018

[blinkpy] Tweak git cl issue

This would make it work correctly if anyone else runs
into the issue with some other message in the output
before the issue number, although this is still just
a hack.

Bug:  868469 
Change-Id: Ib0a66a4374ae4db9807d11feb3d150d261ce0dd6
Reviewed-on: https://chromium-review.googlesource.com/1156994
Reviewed-by: Robert Ma <robertma@chromium.org>
Commit-Queue: Quinten Yearsley <qyearsley@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579560}
[modify] https://crrev.com/027d7020987d56b135c21eb26235f3004c4a70b9/third_party/blink/tools/blinkpy/common/net/git_cl.py
[modify] https://crrev.com/027d7020987d56b135c21eb26235f3004c4a70b9/third_party/blink/tools/blinkpy/common/net/git_cl_unittest.py

@bungeman -- yep, getting the issue with `git config` would probably be better, but may not be worth it now.

Closing for now.

@bungeman -- yep, getting the issue with `git config` would probably be better, but may not be worth it now.

Closing for now.