This is done now thanks to Bitergia. Backend does not contain supybot (IRC) entries anymore. So less data to deal with for everyone. <3

Raising priority because after playing with the (rather new) "Recommendations" function in Hatstall at https://wikimedia.biterg.io/identities/ (which requires me to click at least twice to see details of the two accounts proposed to merge, plus no way to merge the other way round than proposed, meh) there are a lot of proposals which are only based on supybot name (as no other info for IRC accounts than nicknames exist).
I'd generally appreciate switching off and actually deleting the IRC data in the DB because this isn't the best use of my time trying to improve data quality in the DB.

Thank you!

Phabricator metrics are back, I'm closing the task.

I excluded bitergia from the rate limiting requestctl action. I'll check the phabricator dashboard in a few hours and close the task when we have metrics again.

In T374550#10143993, @Jelto wrote:

In T374550#10142554, @Dzahn wrote:

Would we be able to use those in requestctl rules? I guess not but this would be for ./request-ipblocks/known-clients or a new directory there?

I think something like request-ipblocks/known-clients/bitergia.yaml is reasonable place to add the Bitergia IP. I can add the IP Monday morning and exclude it from the Phabricator throttling action.

It would be interesting if they still reach Gerrit and GitLab and stay under the thresholds. But that's probably a topic to discuss in T365259 and T366882.

I added a new known-clients/bitergia.yaml file with the Bitergia IP. commited on puppetserver1001 (not puppetmaster1001 !).

In T374550#10142554, @Dzahn wrote:

Would we be able to use those in requestctl rules? I guess not but this would be for ./request-ipblocks/known-clients or a new directory there?

In T374550#10142576, @Dzahn wrote:

How urgent is this? Is this a daily problem or just like once a month? I will look more tomorrow either way.

How urgent is this? Is this a daily problem or just like once a month? I will look more tomorrow either way.

There was this idea to add a list of friendly networks in our network data.yaml

According to their feedback, that IP is static.

34.175.7.48 belongs to Google/Google Cloud and is already included in our request-ipblocks/cloud/gcp.yaml list. So yes, Bitergia is being unintentionally blocked.

@debt: Great, thanks! If anything is unclear with the instructions in the automated quarterly mail to help prep the Technical Community Newsletter, please let me know!

Hello @Aklapper - yes, I received the email (and yes, it was in my spam folder) and I was able to log in! :)

• I finally updated public https://www.mediawiki.org/w/index.php?title=User%3AAKlapper_%28WMF%29%2FBitergia_data_quality_queries&diff=6736153&oldid=6736146 (thanks Tyler for the nudge)
• I dumped the previous comment in this Phab task into https://www.mediawiki.org/wiki/User:AKlapper_(WMF)/Bitergia_data_quality_queries#Queries_not_possible_due_to_GraphQL_limitations
• I updated non-public https://office.wikimedia.org/wiki/User:AKlapper/continuity#Appendix already a while ago

Should move into separate tasks, however still posting to explain why correcting/updating affiliation data in the Bitergia DB has become more cumbersome:

@debt: Can you confirm that you have received an email from Bitergia (maybe in the spam folder, who knows) on early 2024-08-28, and that you can successfully log in (via https://wikimedia.biterg.io/app/login )? Thanks!

Thanks. Requested in non-public https://support.bitergia.com/support/tickets/1348

Yes, please do the needful, @Aklapper, thanks!

@Lferreira: The internal support ticket has been resolved, so I assume you can access a bunch of things now.
For the records, I requested access to

• https://wikimedia.biterg.io/login (general website)
• https://wikimedia.biterg.io/identities (maintaining account data)
• https://support.bitergia.com/support/ (support ticket tracker for Bitergia and WMF)

If some access is not working as expected, please comment/reopen here.

Requested for user accounts created in Bitergia's non-public https://support.bitergia.com/support/tickets/1303

I am reopening this task which was filed assuming the crawler is not indexing all the Gitlab repositories which is what ticket 1274 tracks now :)

There is a separate ticket about indexing more GitLab repositories at https://support.bitergia.com/support/tickets/1274 which seems to be the actual culprit here.

The current non-public config file indexes 100 code repositories which contain "gitlab" in their URLs.

Regarding https://gitlab.com/Bitergia/c/Wikimedia/sources/blob/master/projects.json , according to https://support.bitergia.com/support/tickets/1251

This repo was abandoned after February's migration. The new one isn't public. We are discussing whether we can update it on demand or commit to keeping the public ones updated.

I updated https://www.mediawiki.org/w/index.php?title=Community_metrics&diff=6556755&oldid=6425860 accordingly.

Well well, followup:

FYI, due to importing RT tickets into Phabricator on 2014-12-17 and due to some tickets originally created either in Bugzilla or in RT being access restricted, there is still a number of non-open tickets filed before 2014-12-17 without a closedEpoch value in the DB.
However the vast majority got fixed today (which might not necessarily fix any statistics if they do not rely on querying the closedEpoch value but e.g. on transaction log values or such).

Done. Thanks everyone!

Database fiddler hero welcome here with production access. Unassigning since I'm not.

Forwarded as https://support.bitergia.com/support/tickets/1251

https://gitlab.com/Bitergia/c/Wikimedia/sources/blob/master/projects.json has not been updated since 2024-02-05 (not sure if that's still the canonical source to pull from for indexing though), and lists 71 repositories.