If you're mentioned in a MR, it shows up in your Todos (https://gitlab.wikimedia.org/dashboard/todos), where you can mark them as Done. So, one option would be for the reviewer-bot to automatically edit the MR description to tag the reviewers, maybe it could create its own section like:

## Reviewers from https://www.mediawiki.org/wiki/Git/Reviewers
* @kharlan 
* @someoneElse

One complication is that you need a mapping of LDAP names to shell user names, i.e. I'm "Kosta Harlan" in gerrit reviewer tagging land, but @kharlan in our GitLab setup.

Side note – does GitLab have some equivalent to gerrit's stream-events?

In T289712#7407683, @kostajh wrote:

Side note – does GitLab have some equivalent to gerrit's stream-events?

I have not yet found a server-wide event stream, but there is a per-project API endpoint for pull monitoring and per-project webhooks for push monitoring. There are also system level webhooks which can notify for new project creation among other things. In theory these could be used in combination to register a project level webhook when notified about the creation of each project to mimic the functionality of a full system feed.

Adding "Gerrit Reviewer Bot" here so that maybe I can find this task quicker in the future. Also pinging @valhallasw into the discussion as the author of the bot that makes this awesome magic work on Gerrit.

See T288381 for the related discussion from two years ago on Wikibugs. Long story short: No, not really, unless you pay for GitLab EE (which I think we don't).

I have no intent in porting gerrit-reviewer-bot to GitLab as the effort is too significant -- I'd say it makes more sense to just start from scratch. The design decisions were driven by what Gerrit offered (in 2012!) on the one hand and what was a convenient 'editable by everyone' system (Mediawiki). None of these decisions are necessarily valid in 2023 with GitLab.

The existing notification system in GitLab would cover most of the entries in https://www.mediawiki.org/wiki/Git/Reviewers. Special handling is still needed for entries that use a file pattern or a repo pattern that doesn't match a single group. This functionality can be added to https://gitlab.wikimedia.org/repos/releng/gitlab-phabricator as an additional "sink". Merge request events don't contain details about what files are touched (that information is only available in a separate push event that is not linked to a merge request), but we can react to MR events by querying https://gitlab.wikimedia.org/api/v4/projects/:id/merge_requests/:merge_request_iid/diffs to get the touched file list when needed.

@valhallasw Can you explain this section of ReviewerFactory._reviewer_generator() in the Gerrit reviewer bot code:
https://github.com/valhallasw/gerrit-reviewer-bot/blob/dcb31716af142494716a35a5fad239add8e368af/add_reviewer.py#L61

elif part.name == "every":
    modulo = self._tryParseInt(part.value, 1)
    if modulo < 2:
        modulo = 1

I wasn't able to find any documentation about an every template parameter. It appears that the intention is to add matching reviewers somewhat probabilistically. I notice in ReviewerFactory._filter_reviewers() that variable i is never advanced past 0 which appears to be a bug.

In T289712#9489602, @dancy wrote:

@valhallasw Can you explain this section of ReviewerFactory._reviewer_generator() in the Gerrit reviewer bot code:
https://github.com/valhallasw/gerrit-reviewer-bot/blob/dcb31716af142494716a35a5fad239add8e368af/add_reviewer.py#L61

elif part.name == "every":
    modulo = self._tryParseInt(part.value, 1)
    if modulo < 2:
        modulo = 1

I wasn't able to find any documentation about an every template parameter. It appears that the intention is to add matching reviewers somewhat probabilistically. I notice in ReviewerFactory._filter_reviewers() that variable i is never advanced past 0 which appears to be a bug.

The idea here was that you'd be able to only get added to half the changesets (or 1/3rd, etc) by providing a divisor. If the changeset ID is divisible by the divisor, you get added, otherwise, you're skipped. I think the i variable was probably just for testing.

FWIW, no-one seems to be using the feature, so it might as well never have existed :-)

dancy opened https://gitlab.wikimedia.org/repos/releng/gitlab-phabricator/-/merge_requests/19

Handle GitLab watches defined in https://www.mediawiki.org/wiki/Git/Reviewers

dancy updated https://gitlab.wikimedia.org/repos/releng/gitlab-webhooks/-/merge_requests/19

Handle GitLab watches defined in https://www.mediawiki.org/wiki/Git/Reviewers

Mentioned in SAL (#wikimedia-releng) [2024-01-29T21:01:06Z] <dancy> Created gitlab-mentions-bot account on GitLab (T289712)

dancy merged https://gitlab.wikimedia.org/repos/releng/gitlab-webhooks/-/merge_requests/19

Handle GitLab watches defined in https://www.mediawiki.org/wiki/Git/Reviewers

dancy opened https://gitlab.wikimedia.org/repos/releng/gitlab-webhooks/-/merge_requests/22

Cache parse_Git_Reviewers() result for 5 minutes by default

dancy merged https://gitlab.wikimedia.org/repos/releng/gitlab-webhooks/-/merge_requests/22

Cache parse_Git_Reviewers() result for 5 minutes by default

https://docs.gitlab.com/ee/api/merge_requests.html#unsubscribe-from-a-merge-request

POST /projects/:id/merge_requests/:merge_request_iid/unsubscribe might be the needed magic after adding a note to drop notifications for the bot itself.

In T289712#9818381, @bd808 wrote:

https://docs.gitlab.com/ee/api/merge_requests.html#unsubscribe-from-a-merge-request

POST /projects/:id/merge_requests/:merge_request_iid/unsubscribe might be the needed magic after adding a note to drop notifications for the bot itself.

Sadly that method doesn't work. I always get a 403 Forbidden response when attempting it. But, the following graphql expression (extracted from the Web UI) works. Annoying.

{"operationName":"mergeRequestSetSubscription","variables":{"fullPath":"dancy/deleteme","iid":"27","subscribedState":false},"query":"mutation mergeRequestSetSubscription($fullPath: ID!, $iid: String!, $subscribedState: Boolean!) {\n  updateIssuableSubscription: mergeRequestSetSubscription(\n    input: {projectPath: $fullPath, iid: $iid, subscribedState: $subscribedState}\n  ) {\n    issuable: mergeRequest {\n      id\n      subscribed\n      __typename\n    }\n    errors\n    __typename\n  }\n}\n"}

dancy opened https://gitlab.wikimedia.org/repos/releng/gitlab-webhooks/-/merge_requests/35

GitlabMentionsSink: Unsubscribe from MR after posting note

dancy merged https://gitlab.wikimedia.org/repos/releng/gitlab-webhooks/-/merge_requests/35

GitlabMentionsSink: Unsubscribe from MR after posting note