Thank you for the fix @matmarex the spikes here were getting distracting on the error dashboards. I really appreciate it <3

Guessing this no longer works since gerrit moved to lit, is that right @Paladox ?

Not seeing any of these in the past 90 days, optimistically closing.

Not seeing any of these in the past 90 days, optimistically resolving.

Still happening as of 2024-04-25

Not seeing any of these over the past 30 days, optimistically resolving.

I note that this started at 2024-04-24 21:35 which matches up with this entry in the SAL:

huh, reply on that page constantly pinging does seem a likely explanation, but I'm curious why we're getting spikes here:

We have a workaround in place involving ssh port forwarding for folks working on catalyst to be able to test the api. This is good enough for now.

In T360911#9724893, @CodeReviewBot wrote:

jhuneidi opened https://gitlab.wikimedia.org/repos/qte/catalyst/patchdemo/-/merge_requests/4

Deploy to k8s

In T362866#9725977, @taavi wrote:

In T362866#9725790, @SCherukuwada wrote:

I think ThisDot should be in the table here: https://www.mediawiki.org/wiki/Gerrit/Privilege_policy#Expedited_process_for_trusted_organisations

I'll see about getting CTO approval to add to that list.

No, that should be discussed on wikitech-l@ or some other similar public venue. The formal RFC process for public discussion of such changes was disbanded a while ago but that does not mean that fundamental policies should be changed unilaterally by the Foundation.

(Also, I don't think adding specific WMF vendors to the list is a good idea. In practice the access would be approved by WMF, not the vendor company itself, and the WMF is already a de facto "trusted organization" per that policy for the mediawiki group as the wmf LDAP group is included in there. So if there are WMF staff members/contractors/vendors that need Gerrit access but not full ldap/wmf access, creating a new group like wmf-mediawiki and giving it similar policy and access status as the existing wmde-mediawiki group has should be easier to manage, both to get that policy change approved and from the point of view of a Gerrit administrator handling such requests.)

Reading the faq answered all the questions I had. No concerns here either.

One gotcha here, post-blubberization, is adding this to trusted runners. Most of the on-wiki documentation for deploying prod services should be relevant.

Thanks extension was chosen pseudo-randomly as a small but representative use-case of production extensions. It may have unforeseen complications, so we should feel free to try a different extension as we develop this.

Stalled pending resolution of parent tasks.