User Details
- User Since
- Feb 3 2019, 8:29 PM (215 w, 17 h)
- Roles
- Administrator
- Availability
- Available
- IRC Nick
- brennen
- LDAP User
- Brennen Bearnes
- MediaWiki User
- BBearnes (WMF) [ Global Accounts ]
Yesterday
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.
Thu, Mar 16
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...
Wed, Mar 15
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.
Tue, Mar 14
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.
Mon, Mar 13
Thu, Mar 9
Wed, Mar 8
Haven't noticed anything recently. Will reopen if it surfaces again.
Mon, Mar 6
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.
Fri, Mar 3
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.
Wed, Mar 1
@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.
Tue, Feb 28
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.
Mon, Feb 27
Fri, Feb 24
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:
Thu, Feb 23
@Dzahn /etc/phabricator and /etc/phabricator/config.yaml are only defined in the main class phabricator which is not present for the aphlict hosts.
Wed, Feb 22
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 :)
Tue, Feb 21
Feb 17 2023
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.