@mmodell and @brennen to pair Soon™ Step 0 dev env for @mmodell

So one thing I think that we need is the equivalent to the "gerrit patches" table that shows up in phabricator for any gerrit patches tagged with Bug: Tnnn I suppose we could use the exact same convention, we just need a way to query gitlab for matching MRs...

I experiemented with a custom issue tracker for the /repos project group.

Works fine ¯\_(ツ)_/¯

You can see in Train Stats MR#2 I wrote Bug: #265617 and it rendered a link here:

In T265617#7413071, @mmodell wrote:

So one thing I think that we need is the equivalent to the "gerrit patches" table that shows up in phabricator for any gerrit patches tagged with Bug: Tnnn I suppose we could use the exact same convention, we just need a way to query gitlab for matching MRs...

Is there documentation for how this is set up with Gerrit?

In T265617#7880480, @kostajh wrote:

In T265617#7413071, @mmodell wrote:

So one thing I think that we need is the equivalent to the "gerrit patches" table that shows up in phabricator for any gerrit patches tagged with Bug: Tnnn I suppose we could use the exact same convention, we just need a way to query gitlab for matching MRs...

Is there documentation for how this is set up with Gerrit?

TLDR: the list of Gerrit patches showing up in Phabricator is custom code that queries Gerrit. If Gitlab indexes issues and offers a REST API to expose all merge requests referencing an issue, we could extend the existing code.

That is a Phabricator customization added by rPHEX7a526af8b46c0b9a0aacd3270a3bc3323ce51a2c for T229934 , upon open a task Phabricator queries the Gerrit REST API for changes associated to the task (via the Gerrit search query bug:Txyz. The first iteration looked like:

The search predicates bug in Gerrit is a functionality that comes from the its-base and its-phabricator Gerrit plugin. its stands for "issue tracking systems", that lets Gerrit process and index metadata found in commit message such as Bug: T1234 which then let the Gerrit API to quickly yields all commits associated with T1234. I am not sure how they end up indexed though, Gerrit config has:

[commentlink "its-phabricator"]
    # $1 must hold the bug number because of the notification bots that are using this.
    match = "\\bT(\\d+)(#\\d+)?\\b(?![#\"]|</a>)"
    link = https://phabricator.wikimedia.org/T$1$2

Gerrit commentlink documentation

The commentlink section I describe above is for rendering. The indexing in Gerrit is done by trackingid config:

Tagged footer lines containing references to external tracking systems, parsed out of the commit message and saved in Gerrit’s secondary index.

We have:

[trackingid "phabricator"]
    footer = Bug:
    match = T\\d+
    system = Phab

That can then be passed to the search predicates tr or bug: https://gerrit.wikimedia.org/r/Documentation/user-search.html#tr

Release-Engineering-Team was poised to look at this this quarter (q4 2022), but the person we intended to have work on it is no longer here so we're behind :(

Moving to our Release-Engineering-Team (Priority Backlog 📥) as we recognize this as an important pre-requisite for moving projects.

Was pointed to this over in T308929: Error: json: cannot unmarshal array on running mw toolhub tools list, do y'all have a test instance of GitLab running? I started to hack around with some webhook/integration stuff — don't mind spinning up my own instance if not

Was pointed to this over in T308929: Error: json: cannot unmarshal array on running mw toolhub tools list, do y'all have a test instance of GitLab running? I started to hack around with some webhook/integration stuff — don't mind spinning up my own instance if not

Yeah, there's one at:

• https://gitlab.devtools.wmcloud.org/
• https://wikitech.wikimedia.org/wiki/GitLab/Test_Instance

You can authenticate there with the usual LDAP credentials.