Page MenuHomePhabricator

Allow hiding of non-discussion comments in Gerrit
Closed, ResolvedPublic

Assigned To
Authored By
Parent5446
Mar 15 2013, 5:19 AM
Referenced Files
F31933639: Screen Shot 2020-07-13 at 16.07.38.png
Jul 13 2020, 2:12 PM
F31933638: Screen Shot 2020-07-13 at 16.07.19.png
Jul 13 2020, 2:12 PM
F31923288: Screen Shot 2020-07-10 at 11.49.22 AM.png
Jul 10 2020, 10:52 AM
F31922482: unfiltered.png
Jul 9 2020, 7:27 PM
F31922484: filtered.png
Jul 9 2020, 7:27 PM
F10392: Capture.PNG
Apr 1 2018, 9:21 PM
Tokens
"Like" token, awarded by Ammarpad."100" token, awarded by kostajh."Party Time" token, awarded by Jdforrester-WMF."Yellow Medal" token, awarded by QChris."Like" token, awarded by xSavitar."Orange Medal" token, awarded by Krinkle."Love" token, awarded by Tgr.

Description

In Gerrit patchsets, comments tend to fall into three categories: 1) the user uploading new patchsets, 2) jenkins verifying the patchset, 3) actual code review comments.

This leads to quite a mind-boggling interface. Example lengthy patch (gerrit 27022):

Capture.PNG (905×1 px, 73 KB)

As a code reviewer, only the highlighted comments would be of any interest.

Recent versions of gerrit support hiding non-comments (1) and also allow hiding CI comments (2) as long as they are tagged (this requires setting a tag field when submitting the change; see docs). The Zuul code creating the review comments would have to be updated to support this.

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:18 AM
bzimport added a project: Gerrit.
bzimport set Reference to bz46148.
bzimport added a subscriber: Unknown Object (MLST).

Just for reference, the screenshot seems to stem from
https://gerrit.wikimedia.org/r/#/c/27022

as a code reviewer, only the highlighted comments would be of any
interest

Why would code reviewing want ignore jenkins output?
Why would code reviewing want ignore newer patch sets?

One solution maybe could be to [...] have the comments be separated
into sections based on patchset.

Comments specific to a patch set are typically made right in the code
(See for example patch set 7 of the referenced change).

To me, comments visible on the change screen are typically high level
comments that rather focus on the change itself than on a specific
detail that's only relevant to a single patch set. Even if such
comments were made when patch set 7 was current, the warnings to
check against ConfirmEdit are still relevant when reviewing patch set

  1. So when tying such comments to a patch set, they'd probably get

lost.

To me, it's a huge benefit to see all the high level comments in a
complete timeline.

While I do not have any concrete metrics for our gerrit instance,
it seems to me that changes with more than a dozen patch sets and
being actively worked on more than five months after opening the
change are rather the exception.

(In reply to comment #1)

Just for reference, the screenshot seems to stem from
https://gerrit.wikimedia.org/r/#/c/27022

as a code reviewer, only the highlighted comments would be of any
interest

Why would code reviewing want ignore jenkins output?
Why would code reviewing want ignore newer patch sets?

It's not that you want to ignore them, it's that they're not comments and yet still mix in as comments. When I want to jump into a patchset and see what discussion is going on, I don't care if Jenkins couldn't merge patchset 6.

Aklapper triaged this task as Lowest priority.Mar 23 2015, 6:59 PM

Gerrit 2.14 seems to include a way for you to hide tagged comments. For example editing a commit msg, you can click the hide tagged comments button and it will hide the comments mentioning you edited the commit msg.

Gerrit 2.14 seems to include a way for you to hide tagged comments. For example editing a commit msg, you can click the hide tagged comments button and it will hide the comments mentioning you edited the commit msg.

Should this task be closed then? (since it seems it's already possible)

There is a "Hide tagged comments" (old UI) / "show comments only" (new UI) option that is supposed to hide the clutter. On gerrit-review.googlesource.com that hides CI comments too, but on gerrit.wikimedia.org it does not. From the code it seems the option will hide any comment that's tagged, so we should tag Jenkins comments.

(Note: comment tags are different from git tags; from T37534: Free-form tagging in gerrit aka hashtags; and from robot comments.)

This will require a change to zuul. To get it to tag comments.

We have upgraded to 2.15 now and using polygerrit ui, and clicking on the "Show comments only" button, it hides the Uploaded patchset <number>.

2.15 looks awesome! Now we only need to tag jenkins-bot, BarryTheBrowserTestBot and Cindy-the-browser-test-bot as bots.
(There are some other bot gerrit accounts: Jenkins-mwext-sync, L10n-bot, Libraryupgrader, Maintenance-bot, Pywikipedia Conversion Bot, Release notes rebase bot, Reviewer-bot. I don't think any of those create comments though.)

gerrit-review.googlesource.com has a "Comment threads" mode, which adds another level of awesome. Is that a version difference? They are also on 2.15.2.

@Tgr upstream use the master branch, it has alot of new features to polygerrit. this will be in 2.16 / 3.0.

Upstream may be planning on branching a new release in the next couple of weeks (not sure). Upstream are working towards removing gwtui now so the new release will be the last to support gwtui.

Upstream show 2.15.2 due to the way the version system works. but basically they are running 2.16 / 3.0.

You can test this at https://gerrit-new.wmflabs.org/r/

hashar added a subscriber: hashar.

Gave it a try on https://gerrit.wikimedia.org/r/#/c/test/gerrit-ping/+/226272/ By using:

gerrit review --tag CI --message 'Testing addition of a CI tag' 226272,3

So I guess in the Zuul configuration it is all about passing tag: autogenerated:ci in the various gerrit reports:

 pipelines:
   - name: test
      success-message:  'Main test build succeeded.'
      success:
        gerrit:
          verified: 2
+         tag: autogenerated:ci

The autogenerated prefix should cause the comments to automatically be hidden in the new UI (polygerrit).

Doesn't seem to work for the linked patch. OTOH per T217008#5908642 a plain tag: autogenerate works and is already being used for SonarQube (and is super nice) - would be great to have that for the rest of the bots.

The example I gave with --tag CI was wrong. But if I prefix it with autogenerated:: --tag=autogenerated:ci the message can then be filtered out.

Aklapper added a subscriber: Aklapper.

@hashar: A good first task is a self-contained, non-controversial task with a clear approach and links to documentation and the codebase (see the project description). Given the current task description I'm removing the good first task tag.

Change 610361 had a related patch set uploaded (by Hashar; owner: Hashar):
[integration/config@master] zuul: let Gerrit filterout CI reviews

https://gerrit.wikimedia.org/r/610361

I dropped this task from our onboarding milestone cause it turns out to require knowledge about a lot of areas so that is not very suitable :] I think the above patch might work, at least the generated gerrit review commands sound legit.

Mentioned in SAL (#wikimedia-releng) [2020-07-09T19:15:49Z] <hashar> Reloading Zuul to have messages to gerrit tagged with 'autogenerated:ci' | https://gerrit.wikimedia.org/r/c/integration/config/+/610361 | T48148

Change 610361 merged by jenkins-bot:
[integration/config@master] zuul: let Gerrit filterout CI reviews

https://gerrit.wikimedia.org/r/610361

Change 610907 had a related patch set uploaded (by Hashar; owner: Hashar):
[test/gerrit-ping@master] Exerice CI and check autogenerated:ci comments

https://gerrit.wikimedia.org/r/610907

Change 610907 abandoned by Hashar:
[test/gerrit-ping@master] Exerice CI and check autogenerated:ci comments

Reason:
Seems like that is working as intended ;]

https://gerrit.wikimedia.org/r/610907

And 7 years later that is now possible. I have send a dummy change for demo purposes https://gerrit.wikimedia.org/r/c/test/gerrit-ping/+/610907 and I made a dummy comment (and CI did as well):

unfiltered.png (348×952 px, 45 KB)

After clicking Only comments:

filtered.png (128×950 px, 14 KB)

@Tgr does that look any correct?

Awesome, thank you for fixing that!

So that is essentially done for Zuul / jenkins-bot. We could use the same system for the other various bots mentioned at T48148#4269388 :)

Thank you @Tgr for spotting the issue in upstream Gerrit and @Paladox for the guidance. It is rolled for Zuul / jenkins-bot which is arguably the largest spammer. SonarQubeBot already uses it as far as I understand.

I am not sure, but me I am still seeing Jenkins-bot comments even after toggling 'Only comments' (r604184)

Screen Shot 2020-07-10 at 11.49.22 AM.png (482×1 px, 171 KB)

@Ammarpad unfortunately it won't work retroactively, as Antoine noted in the email to wikitech-l

Do note that old CI messages written for the last 9 years or so are not tagged and can not be filtered out.

@Ammarpad indeed those recent messages from jenkins-bot on patchset 10 are not properly tagged for some reason. They can be inspected with:

cd mediawiki/extensions/UniversalLanguageSelector
git fetch origin refs/changes/84/604184/meta
git log FETCH_HEAD

One of those comment looks like:

commit fc513a695df74a865726a449953bf7c6713fcfe2
Author: Gerrit User 75 <75@e9e9afe9-4712-486d-8885-f54b72dd1951>
Date:   Mon Jul 6 23:21:40 2020 +0000

    Update patch set 10
    
    Patch Set 10:
    
    PHP test coverage increased (or stayed the same) :-)
    
    - mwext-phpunit-coverage-patch-docker https://integration.wikimedia.org/ci/job/mwext-phpunit-coverage-patch-docker/29582/console : SUCCESS in 2m 05s
    
    Patch-set: 10
    Reviewer: Gerrit User 75 <75@e9e9afe9-4712-486d-8885-f54b72dd1951>

It should have a Tag: autogenerated:ci :-\

Thank you all. On newer patches I am not seeing the issue, so it's OK

Oh no sorry I got confused because the comment are made on Patchset 10 and I thought it was July 10th.

The reason for those commits to not be tagged is that they have been before has been deployed ( https://gerrit.wikimedia.org/r/610361 ). So essentially any comments made before that are not tagged and thus can not be filtered out.

I do not think we have a way to easily tag the old messages without potentially breaking the git repository history :-\

It looks like the new tagged bot comments no longer have an option to reply to them (example comments from this change – left comment is untagged, right comment is tagged):

Screen Shot 2020-07-13 at 16.07.19.png (303×801 px, 74 KB) Screen Shot 2020-07-13 at 16.07.38.png (473×801 px, 131 KB)

Is it possible to restore the “Reply” button? I find it useful sometimes, to comment on the individual FAILURE lines (example comment).

On Gerrit master CI checks are rendered differently, so you can't quote them anyway. Not sure if that's another Gerrit upgrade away, or just a matter of configuration. See the Checks tab here. (That commit itself is somewhat relevant to this task BTW, although at the time of writing it has not been merged yet.)

In T48148#6316142, @Tgr wrote:

On Gerrit master CI checks are rendered differently, so you can't quote them anyway.

And while it looks pretty nice, at least the integration on gerrit-review is not especially robust. I've had many changes where one received overall +1 votes although some checks failed.

Not sure if that's another Gerrit upgrade away, or just a matter of configuration.

We'd need to install the checks plugin for that tab. So it's more than a config change. But note that our Zuul does not speak the required protocol. So the plugin alone would not do. We'd need to build a bridge between our old Zuul and the plugin (or upgrade Zuul, because IIRC latest Zuul learnt to speak that API).

Regardless of the above, upstream gerrit recently announced that they'll stop working on the checks plugin and will redo the CI integration part. So it's not clear if the checks plugin is the future or even has a future.

Putting those things together makes me think that what we have is probably a good and stable choice for now.

Note the Gerrit checks plugin is being abandoned. They are rethinking it entirely, from https://groups.google.com/g/repo-discuss/c/QYZFCvh_x98/m/z2uyvVrLAAAJ Gerrit CI experience reboot:

Dear Gerrit users, admins and developers,

We have been working on a new strategy for surfacing CI results in Gerrit. This means that we are stopping work on the checks plugin. The new strategy is documented in “Gerrit CI Experience Reboot (public)”. I hope you like it.

We are currently working on gathering detailed requirements from our internal partners. If you are interested in helping us gather requirements, please send me or bro...@google.com an email, so we can set up a channel to collect your input.

It looks like the new tagged bot comments no longer have an option to reply to them (example comments from this change – left comment is untagged, right comment is tagged):

Screen Shot 2020-07-13 at 16.07.19.png (303×801 px, 74 KB) Screen Shot 2020-07-13 at 16.07.38.png (473×801 px, 131 KB)

Is it possible to restore the “Reply” button? I find it useful sometimes, to comment on the individual FAILURE lines (example comment).

Sounds it might be a valid enhancement request, even though I am not sure how often people would want to reply to a robot comment, but surely that might happen. I would guess there is some tweak to be made in the Gerrit javascript somewhere. I haven't looked at Gerrit code though.

Should be hold this task on it or do we mark it resolved and file another one?

It looks like the new tagged bot comments no longer have an option to reply to them (example comments from this change – left comment is untagged, right comment is tagged):

Screen Shot 2020-07-13 at 16.07.19.png (303×801 px, 74 KB) Screen Shot 2020-07-13 at 16.07.38.png (473×801 px, 131 KB)

Is it possible to restore the “Reply” button? I find it useful sometimes, to comment on the individual FAILURE lines (example comment).

Seems tha is done on purpose, the messages whose tag starts with autogenerated are considered automated ones and that gets the reply button hidden:

polygerrit-ui/app/elements/change/gr-message/gr-message.js
  _computeShowReplyButton(message, loggedIn) {
    return message && !!message.message && loggedIn &&
        !this._computeIsAutomated(message);
  }

...

  _computeIsAutomated(message) {
    return !!(message.reviewer ||
        this._computeIsReviewerUpdate(message) ||
        (message.tag && message.tag.startsWith('autogenerated')));
  }

I don't think we should bother much, that seems to be a very narrow corner case

Forgot to mark this one resolved. That has been done by upgrading to Gerrit 3.2 and having bots to tag their comments with a tag starting with autogenerated.