But in general, OAuth is one of the tools (along with some other "global" extensions like CentralAuth) where group1 (meta) is used even for things that are, from a user perspective, Wikipedia-related (e.g. the Wikipedia Library), so we should probably react more aggressively to group1 errors coming from such extensions. @brennen not sure if there's a good place to document that.

Seems fixed in production; removing as train blocker, leaving open for any needed followup.

We can roll back if necessary, but looks like @Jdforrester-WMF's patch above should be ready shortly...

End-of-workday status: Not rolling back for T321160, but holding at group1.

Looking at code, should be a simple fix. Reverted in production in the meanwhile.

Fallout of recent deployment

Also worked T155130 in here.

New error message:

Resolved with T331915: Phabricator deployment 2023-03-15.

Deployed.

This should work now. I was able to see an example on the Release-Engineering-Team workboard - the task for the Phabricator deployment: T331915.

This is cropping back up after T330205: 1.40.0-wmf.27 deployment blockers deploy.

No objections here.

Good catch and thanks for the task - I remember thinking I needed to drop one in there, but I obviously didn't follow up.

Haven't noticed anything recently. Will reopen if it surfaces again.

I still need to confirm that it works, but I'm looking to get a Phabricator deploy window scheduled some time this week, so hopefully not long.

My vote is for standardizing on Tnnn, as that is what I expect as a Phabricator user. It also avoids your ambiguity issue.

I confirmed the new CodeReviewBot user works here - T324164#8664674 - but haven't permanently switched to that yet since I need to make sure it works with phabricator maintenance bot.

@CodeReviewBot exists now.

@xcollazo wrote:

Per discussion on this pull request to Phabricator-maintenance-bot for patch-for-review tagging, I'm going to create a CodeReviewBot in Phab and switch to using that for GitLab MR notices.

Pattern matching on Phabricator URLs is something we could add pretty trivially, and seems like a reasonable idea.

In my imagination the perfect migration and least error prone would be if nothing at all changes when I clone the repo ... but whenever I have the idea to change something I obviously notice I can't push to it anymore and then when I go to the UI I see a large banner on the repo detail page that informs me that it moved to Gitlab and how I should change my git source.

Removing GitLab; please re-tag if I missed something relevant.

This ticket mostly discusses the technical implementation; have we decided as a policy matter that e.g. GitLab issues should not be used?

For what it's worth, GitLab admins can adjust the messages here:

@Dzahn /etc/phabricator and /etc/phabricator/config.yaml are only defined in the main class phabricator which is not present for the aphlict hosts.

Kind of piggyback riding: Somehow updating the custom Source Repo field in Phabricator project descriptions would also be very neat (but a separate request).

I am reopening the task since it is still reporting Gitlab actions as @gerritbot :)

dylsss updated https://gitlab.wikimedia.org/repos/phabricator/phabricator/-/merge_requests/1

FWIW, this is probably either not a big deal to add or kind of a pain. I can investigate which. Maybe it could be a patch to Phorge.