[00:11:11] DannyS712: Is there a task about flaky MediaWiki\Tests\Storage\NameTableStoreTest::testGetName - re https://gerrit.wikimedia.org/r/c/mediawiki/core/+/649463 [00:15:19] no idea, not that I've seen [00:16:10] but there should be, since its also failing at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/649397 which has nothing related to NameTableStore [00:16:17] let me look, and if not I'll file on [00:16:18] one [00:16:43] Sounds good, yeah, that'd be great! [00:17:38] James_F: from mediawiki-commits@: [00:17:42] List: MediaWiki-commits [00:17:44] Member: forrestbot@gmail.com [00:17:46] Action: Subscription disabled. [00:17:48] Reason: Excessive or fatal bounces. [00:18:00] is that a le.go thing or? [00:18:22] valhallas.w? [00:20:15] T270144 [00:20:16] T270144: Flaky test MediaWiki\Tests\Storage\NameTableStoreTest::testGetName - https://phabricator.wikimedia.org/T270144 [00:24:46] ^ filed a bug report, don't see any recent changes that might have caused it at first glance [00:24:53] greg-g: Hmm, that's not good, the bot relies on that to get the updates. [00:24:58] greg-g: That's ReleaseTaggerBot. [00:26:16] right, who is that? [00:26:38] aha, the two people I thought after you :) [00:26:43] Correct. :-) [00:26:47] legoktm: ^^ [00:27:08] hi [00:27:11] hola! [00:27:27] I think that's because of the gmail outage [00:27:41] ohhh, could be [00:27:51] Oh, right, yeah, I imagine a bunch of us got bounces. [00:28:00] it doesn't say they were unsub'd in this email, so hopefully it's still getting new mails now [00:28:15] oh no, it does, subscription disabled. [00:28:29] * greg-g was reading during a finance/budget meeting ;) [00:28:30] let me find the password [00:29:56] the most recent email in the inbox is [00:30:02] > You have been unsubscribed from the MediaWiki-commits mailing list [00:30:23] :( [00:30:31] I guess I'll just resubscribe [00:32:34] hm, the confirmation email isn't coming [00:32:42] nvm, I was impatient [00:34:02] * legoktm looks for a change to merge [00:34:12] Merge all the things., [00:41:04] email received, now manually running forrestbot [00:41:54] greg-g, James_F: we should be all set now [00:43:08] thanks for the ping [00:45:05] Hurrah. [00:50:52] Thanks! [01:16:53] legoktm: gerritreviewerbot@gmail.com too :/ [01:17:09] * greg-g is at the skate park [01:17:35] greg-g: ugh, thanks [01:19:24] I hope valhallasw didn't get a text oops [01:22:12] fixed [01:24:45] (sent him a mail too) [01:25:26] I wonder if we should convert those two tools to use the change stream instead [01:35:10] Yes, though is it worth it if we're dumping gerrit in a few months'/years' time? [02:08:17] Krinkle did you see my comments on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/646805 before your +2 ? [02:10:29] No, but I do read my email notifs and just saw it. [03:40:23] 10Gerrit, 10Trust-and-Safety, 10cloud-services-team (Kanban): Cannot login gerrit.wikimedia.org with wikitech.mediawiki.org account - https://phabricator.wikimedia.org/T270064 (10Andreg-p) Thank you so much, everybody. And once more, sorry for the mess! [03:41:50] 10Gerrit, 10Trust-and-Safety, 10cloud-services-team (Kanban): Cannot login gerrit.wikimedia.org with wikitech.mediawiki.org account - https://phabricator.wikimedia.org/T270064 (10Andreg-p) 05Open→03Resolved p:05Triage→03Unbreak! [03:46:45] 10Gerrit, 10Trust-and-Safety, 10cloud-services-team (Kanban): Cannot login gerrit.wikimedia.org with wikitech.mediawiki.org account - https://phabricator.wikimedia.org/T270064 (10JJMC89) p:05Unbreak!→03Medium [06:15:53] James_F: probably not. And email is generally more resilient than stream-changes, today was really an exception [06:41:58] (03PS1) 10Samwilson: Add labs/tools/extjsonuploader [integration/config] - 10https://gerrit.wikimedia.org/r/649489 (https://phabricator.wikimedia.org/T250344) [09:01:25] 10Release-Engineering-Team, 10Gerrit-Privilege-Requests, 10TechCom: Create WikiTeq group on Gerrit - https://phabricator.wikimedia.org/T267213 (10Kizule) Hi, is there any progress here? [09:57:26] 10Beta-Cluster-Infrastructure, 10Growth-Team (Current Sprint): Create beta bnwiki - https://phabricator.wikimedia.org/T270165 (10Tgr) [10:42:39] 10Beta-Cluster-Infrastructure, 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO, 10Patch-For-Review, and 3 others: Remove deployment.wikimedia.beta.wmflabs.org wiki (deploymentwiki) - https://phabricator.wikimedia.org/T198673 (10Majavah) I think we're good to proceed, no-on... [10:56:49] 10Beta-Cluster-Infrastructure, 10Release-Engineering-Team, 10Operations: Puppet failure on deployment-cache-text06 - https://phabricator.wikimedia.org/T256064 (10jbond) [11:56:17] kostajh: Hi, do you plan to meet about quibble today? I haven't seen hashar this morning... [11:58:04] awight: hi, I just declined the meeting. we're back in lockdown, so synchronous meetings are kind of impossible right now. [11:59:21] 10Release-Engineering-Team (Deployment services), 10Patch-For-Review, 10SDAW-MediaSearch (MediaSearch-ReleaseCandidate), 10Structured-Data-Backlog (Current Work), 10Wikimedia-extension-review-queue: Split MediaSearch out into its own extension - https://phabricator.wikimedia.org/T265939 (10matthiasmullie... [12:00:03] kostajh: good luck! [12:00:57] The apache work is at a tipping point, fyi. We have the experimental job running, and it seems to be failing because of database deadlock. Maybe the db is running single-threaded? [12:04:13] awight: could you point me to a failure? [12:05:18] awight: did you test MySQL with the experimental job? T259685 might be related if you're looking at SQLite [12:05:22] T259685: Zeroconf VisualEditor/Parsoid doesn't work on SQLite - https://phabricator.wikimedia.org/T259685 [12:07:19] 10Release-Engineering-Team, 10Gerrit-Privilege-Requests, 10TechCom: Create WikiTeq group on Gerrit - https://phabricator.wikimedia.org/T267213 (10daniel) >>! In T267213#6691189, @Kizule wrote: > Hi, is there any progress here? In the TechCom meeting last Wednesday, we agreed that WikiTeq can be added as a t... [12:07:24] I was assuming MySQL, but lemme look closer... [12:08:30] (03CR) 10Kosta Harlan: [C: 03+1] "recheck" [integration/quibble] - 10https://gerrit.wikimedia.org/r/644178 (owner: 10Kosta Harlan) [12:08:44] kostajh: Here's the job, https://integration.wikimedia.org/ci/view/CI/job/integration-quibble-apache-fullrun/ [12:09:26] awight: ah, ok. so with mysql [12:10:04] awight: "Exception caught: A database query error has occurred. This may indicate a bug in the software." It's possible there's a bug in the software :) [12:10:09] hahaha [12:10:35] 10Beta-Cluster-Infrastructure, 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO, 10Patch-For-Review, and 3 others: Remove deployment.wikimedia.beta.wmflabs.org wiki (deploymentwiki) - https://phabricator.wikimedia.org/T198673 (10Majavah) According to https://wikitech.wikime... [12:10:37] I somehow decided this was a deadlock. Scrounging to find that... [12:10:46] awight: https://integration.wikimedia.org/ci/view/CI/job/integration-quibble-apache-fullrun/8/artifact/log/mw-error.log [12:11:01] ty [12:12:16] So the software should retry /o\ [12:13:33] Maybe this is the first of a long line of bugs to be revealed by increasing CI concurrency? [12:14:44] awight: seems possible [12:16:44] 10Beta-Cluster-Infrastructure, 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO, 10Patch-For-Review, and 3 others: Remove deployment.wikimedia.beta.wmflabs.org wiki (deploymentwiki) - https://phabricator.wikimedia.org/T198673 (10Majavah) The two uses for that dblist that I... [12:18:47] I'm rerunning the job just to see if it crashes on the same tests. [12:22:59] awight: good idea [12:23:52] awight: I think I recall some discussion about the failing RC test [12:25:46] !log Create beta bnwiki (T270165) [12:25:49] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [12:25:49] T270165: Create beta bnwiki - https://phabricator.wikimedia.org/T270165 [12:26:19] awight: just a guess, but perhaps T230211 is related [12:26:20] T230211: Enable API integration tests to ensure that GET requests will always see the effect of previous POST requests. - https://phabricator.wikimedia.org/T230211 [12:29:02] kostajh: Same error in a different place, now: https://integration.wikimedia.org/ci/view/CI/job/integration-quibble-apache-fullrun/9/console [12:32:12] 10Beta-Cluster-Infrastructure, 10Growth-Team (Current Sprint), 10Patch-For-Review, 10User-Urbanecm: Create beta bnwiki - https://phabricator.wikimedia.org/T270165 (10Urbanecm) p:05Triage→03Low a:03Urbanecm [12:32:14] 10Beta-Cluster-Infrastructure, 10Growth-Team (Current Sprint), 10Patch-For-Review, 10User-Urbanecm: Create beta bnwiki - https://phabricator.wikimedia.org/T270165 (10Urbanecm) I took the liberty to create the wiki :). [12:33:53] 10Release-Engineering-Team, 10Gerrit-Privilege-Requests, 10TechCom: Create WikiTeq group on Gerrit - https://phabricator.wikimedia.org/T267213 (10Pastakhov) >>! In T267213#6669371, @ssastry wrote: > FWIW, I've worked with @pastakhov of WikiTeq during the porting of Parsoid from JS to PHP and found them compe... [12:33:54] awight: ok I will try to investigate later [12:34:35] The RC test will probably fail from time to time as there is no guarantee the recent change feed will contain the output from the POST, due to deferred update execution [12:43:11] Ideally, we could tune mysql to make these overlapping transactions less destructive. But I don't know if that's a thing? [13:04:12] kostajh: awight: I had kids for lunch again :/ [13:04:23] well :/ cause I have skip the quibble meeting [13:04:29] :] cause I had kids at home hehe [13:04:55] the recentchange test, indeed that failed a previously. Some attempt was to hit the main page repeatedly to trigger jobs run [13:05:14] and I think later we introduced a token that lets one run the jobs over the API (that was required for api-testing ) [13:12:09] hashar: I had to read that a couple of times to realise what you meant [13:12:17] "Why did hashar eat his kids for lunch?" [13:12:22] hahaha [13:27:27] kostajh: btw, there is currently no "check experimental" wiring to trigger the apache job, you'll have to "rebuild" in the Jenkins console. [13:49:23] 10Phabricator, 10Operations, 10Security: Phabricator unresponsive - https://phabricator.wikimedia.org/T270184 (10jbond) p:05Triage→03Medium [16:09:17] (03PS1) 10Jforrester: Zuul: Install CI for mediawiki/libs/RequestTimeout [integration/config] - 10https://gerrit.wikimedia.org/r/649664 (https://phabricator.wikimedia.org/T269326) [16:11:43] (03CR) 10Jforrester: [C: 03+2] Zuul: Install CI for mediawiki/libs/RequestTimeout [integration/config] - 10https://gerrit.wikimedia.org/r/649664 (https://phabricator.wikimedia.org/T269326) (owner: 10Jforrester) [16:13:18] (03Merged) 10jenkins-bot: Zuul: Install CI for mediawiki/libs/RequestTimeout [integration/config] - 10https://gerrit.wikimedia.org/r/649664 (https://phabricator.wikimedia.org/T269326) (owner: 10Jforrester) [16:13:30] !log Zuul: Install CI for mediawiki/libs/RequestTimeout T269326 [16:13:34] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [16:13:34] T269326: RequestTimeout library - https://phabricator.wikimedia.org/T269326 [16:14:45] (03PS2) 10Jforrester: Zuul: Install CI for labs/tools/extjsonuploader [integration/config] - 10https://gerrit.wikimedia.org/r/649489 (https://phabricator.wikimedia.org/T250344) (owner: 10Samwilson) [16:15:12] (03CR) 10Jforrester: [C: 03+2] Zuul: Install CI for labs/tools/extjsonuploader [integration/config] - 10https://gerrit.wikimedia.org/r/649489 (https://phabricator.wikimedia.org/T250344) (owner: 10Samwilson) [16:16:31] (03Merged) 10jenkins-bot: Zuul: Install CI for labs/tools/extjsonuploader [integration/config] - 10https://gerrit.wikimedia.org/r/649489 (https://phabricator.wikimedia.org/T250344) (owner: 10Samwilson) [16:16:40] !log Zuul: Install CI for labs/tools/extjsonuploader T250344 [16:16:42] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [16:16:43] T250344: Add config, tests, and convert to PSR4 - https://phabricator.wikimedia.org/T250344 [16:19:01] 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO, 10Operations, 10serviceops, and 2 others: Upgrade MediaWiki clusters to Debian Buster (debian 10) - https://phabricator.wikimedia.org/T245757 (10ops-monitoring-bot) Script wmf-auto-reimage was launched by hnowlan on cumin100... [16:24:49] 10phan-taint-check-plugin: Trial taint-check against DVWA - https://phabricator.wikimedia.org/T270193 (10Daimona) [16:56:15] 10Continuous-Integration-Infrastructure, 10Patch-For-Review: Provide python 3.8 in CI test images - https://phabricator.wikimedia.org/T268850 (10ssingh) Hi, thanks for your work on this task! Is my understanding correct that this blocks on T241195? [16:57:20] 10Continuous-Integration-Infrastructure, 10Patch-For-Review: Provide python 3.8 in CI test images - https://phabricator.wikimedia.org/T268850 (10Jdforrester-WMF) >>! In T268850#6692686, @ssingh wrote: > Hi, thanks for your work on this task! Is my understanding correct that this blocks on T241195? Yes, this i... [17:09:13] maryum: success!! [17:09:22] hashar: really? how [17:09:27] maryum: eventually the analysis worked on my local machine for some reason [17:09:31] and states: [INFO] 18:05:42.207 ANALYSIS SUCCESSFUL, you can find the results at: https://sonarcloud.io/dashboard?id=org.wikidata.query.rdf%3Aflink-fs-swift [17:10:10] so maybe the sonar java-codehealth-path job that runs when a change is uploaded is fixed as well [17:16:54] 10Continuous-Integration-Config, 10Code-Health, 10Discovery-Search (Current work), 10Patch-For-Review: Ensure that SonarQube is commenting on gerrit code reviews of the Search Platform team - https://phabricator.wikimedia.org/T264873 (10hashar) We paired about it with @Mstyles and @Gehel there are a few di... [17:30:06] 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO, 10Operations, 10serviceops, and 2 others: Upgrade MediaWiki clusters to Debian Buster (debian 10) - https://phabricator.wikimedia.org/T245757 (10ops-monitoring-bot) Completed auto-reimage of hosts: ` ['mw1265.eqiad.wmnet'] `... [17:35:33] hashar: maybe, I can create another test patch to see [17:35:45] maryum: yeah I have send a dummy one [17:36:00] https://gerrit.wikimedia.org/r/c/wikidata/query/flink-swift-plugin/+/649709 :) [17:36:18] looks like it is working after I ran sonar:sonar on my local machine [17:37:24] https://sonarcloud.io/dashboard?id=org.wikidata.query.rdf%3Aflink-fs-swift&branch=649709-1 ! [17:37:33] then I have no idea whether the report contains the proper stuff [17:38:44] I still don't think the patches are being properly analyzed [17:39:05] seems like there should be something here: https://sonarcloud.io/code?branch=649709-1&id=org.wikidata.query.rdf%3Aflink-fs-swift [17:40:09] maryum: possibly yes, that would be to be investigated with gehel I guess [17:40:27] yep, I'll keep looking into that part [17:58:28] (03PS2) 10Dduvall: Add mediawiki project pipeline wmf-publish [integration/config] - 10https://gerrit.wikimedia.org/r/649441 (https://phabricator.wikimedia.org/T269617) [18:01:31] !log deploying 2 new jenkins jobs for https://gerrit.wikimedia.org/r/c/integration/config/+/649441 [18:01:33] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [18:02:33] (03CR) 10Dduvall: [C: 03+1] "INFO:jenkins_jobs.builder:Number of jobs generated: 2" [integration/config] - 10https://gerrit.wikimedia.org/r/649441 (https://phabricator.wikimedia.org/T269617) (owner: 10Dduvall) [18:02:43] (03CR) 10Dduvall: [C: 03+2] Add mediawiki project pipeline wmf-publish [integration/config] - 10https://gerrit.wikimedia.org/r/649441 (https://phabricator.wikimedia.org/T269617) (owner: 10Dduvall) [18:04:07] (03Merged) 10jenkins-bot: Add mediawiki project pipeline wmf-publish [integration/config] - 10https://gerrit.wikimedia.org/r/649441 (https://phabricator.wikimedia.org/T269617) (owner: 10Dduvall) [18:05:20] !log reloading zuul to deploy https://gerrit.wikimedia.org/r/c/integration/config/+/649441 [18:05:22] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [18:05:35] (03PS3) 10DannyS712: Check for object and object[] on @var docs [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/644296 (owner: 10Umherirrender) [18:05:38] (03CR) 10DannyS712: [C: 03+2] Check for object and object[] on @var docs [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/644296 (owner: 10Umherirrender) [18:05:46] 10Continuous-Integration-Config, 10Code-Health, 10Discovery-Search (Current work), 10Patch-For-Review: Ensure that SonarQube is commenting on gerrit code reviews of the Search Platform team - https://phabricator.wikimedia.org/T264873 (10kostajh) >>! In T264873#6692797, @gerritbot wrote: > Change 649709 **a... [18:07:10] (03Merged) 10jenkins-bot: Check for object and object[] on @var docs [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/644296 (owner: 10Umherirrender) [18:07:34] (03PS2) 10DannyS712: Avoid slow strcasecmp() where not necessary [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/647205 (owner: 10Thiemo Kreuz (WMDE)) [18:07:36] (03CR) 10DannyS712: [C: 03+2] Avoid slow strcasecmp() where not necessary [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/647205 (owner: 10Thiemo Kreuz (WMDE)) [18:08:50] (03Merged) 10jenkins-bot: Avoid slow strcasecmp() where not necessary [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/647205 (owner: 10Thiemo Kreuz (WMDE)) [18:16:07] (03CR) 10Hashar: "* <--- that is a barn star :]" [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/647205 (owner: 10Thiemo Kreuz (WMDE)) [18:24:23] ^ lol [18:24:52] 10Project-Admins, 10Security-Team, 10User-RhinosF1: Create acl*miraheze-sysadmins for security tasks we file - https://phabricator.wikimedia.org/T270203 (10RhinosF1) [18:32:14] 10Release-Engineering-Team-TODO (2020-10-01 to 2020-12-31 (Q2)), 10Patch-For-Review, 10Release, 10Train Deployments: 1.36.0-wmf.22 deployment blockers - https://phabricator.wikimedia.org/T267415 (10Krinkle) [18:35:15] (03CR) 10Dduvall: "> Patch Set 1: Code-Review+1" [integration/pipelinelib] - 10https://gerrit.wikimedia.org/r/649445 (owner: 10Dduvall) [18:49:07] 10phan-taint-check-plugin: Trial taint-check against DVWA - https://phabricator.wikimedia.org/T270193 (10Daimona) Meh, the results of the experiments: - Several issues were detected as expected - There are a couple of false negatives and false positives, but in places where it's reasonable to expect them - Th... [19:03:07] 10Continuous-Integration-Config, 10Release-Engineering-Team (CI & Testing services), 10Release-Engineering-Team-TODO (2020-10-01 to 2020-12-31 (Q2)), 10MediaWiki-skins-WikimediaApiPortal: Create a coverage job for skins - https://phabricator.wikimedia.org/T265407 (10eprodromou) [19:06:09] 10Project-Admins, 10Security-Team, 10User-RhinosF1: Create acl*miraheze-sysadmins for security tasks we file - https://phabricator.wikimedia.org/T270203 (10Legoktm) Given that "Miraheze sysadmins" includes a WMF globally banned user, I don't see why we would do this. [19:07:25] is "Release pipeline (blubber)" the correct phab project for blubber bugs? [19:07:32] 10Project-Admins, 10Security-Team, 10User-RhinosF1: Create acl*miraheze-sysadmins for security tasks we file - https://phabricator.wikimedia.org/T270203 (10RhinosF1) >>! In T270203#6693084, @Legoktm wrote: > Given that "Miraheze sysadmins" includes a WMF globally banned user, I don't see why we would do this... [19:28:36] legoktm: yeah [19:28:58] thanks [19:29:30] 10Project-Admins, 10Security-Team, 10User-RhinosF1: Create acl*miraheze-sysadmins for security tasks we file - https://phabricator.wikimedia.org/T270203 (10jrbs) > All Miraheze sysadmins have NDAs as part of their role. With the Foundation? How does this work? With the caveat that Phabricator isn't an are... [19:46:42] 10Project-Admins, 10Security-Team, 10User-RhinosF1: Create acl*miraheze-sysadmins for security tasks we file - https://phabricator.wikimedia.org/T270203 (10RhinosF1) >>! In T270203#6693161, @jrbs wrote: >> All Miraheze sysadmins have NDAs as part of their role. > > With the Foundation? How does this work?... [19:49:41] 10Project-Admins, 10Security-Team, 10User-RhinosF1: Create acl*miraheze-sysadmins for security tasks we file - https://phabricator.wikimedia.org/T270203 (10Aklapper) What would be the exact and complete workflow of maintaining membership in this acl tag, and which steps would you perform when creating a Phab... [19:50:49] 10Project-Admins, 10Security-Team, 10User-RhinosF1: Create acl*miraheze-sysadmins for security tasks we file - https://phabricator.wikimedia.org/T270203 (10jrbs) >>! In T270203#6693186, @RhinosF1 wrote: > Just with us. It would cover security issues reported to or found by us and filed upstream. In my non-l... [19:52:18] 10Project-Admins, 10Security-Team, 10User-RhinosF1: Create acl*miraheze-sysadmins for security tasks we file - https://phabricator.wikimedia.org/T270203 (10RhinosF1) >>! In T270203#6693194, @Aklapper wrote: > What would be the exact and complete workflow of maintaining membership in this acl tag? It would be... [19:54:33] 10Project-Admins, 10Security-Team, 10User-RhinosF1: Create acl*miraheze-sysadmins for security tasks we file - https://phabricator.wikimedia.org/T270203 (10RhinosF1) >>! In T270203#6693195, @jrbs wrote: > In my non-legal opinion I'm not sure this is really good enough for our purposes. Our standard procedure... [21:43:51] (03PS2) 10Jforrester: jjb: use same image in coverage publish job [integration/config] - 10https://gerrit.wikimedia.org/r/647194 (owner: 10Hashar) [21:43:53] (03PS5) 10Jforrester: jjb: Provide PHP 7.3, 7.4, and 8.0 versions of PHPUnit coverage publish job [integration/config] - 10https://gerrit.wikimedia.org/r/628589 [21:47:09] (03CR) 10Jforrester: [C: 03+2] jjb: use same image in coverage publish job [integration/config] - 10https://gerrit.wikimedia.org/r/647194 (owner: 10Hashar) [21:48:35] (03Merged) 10jenkins-bot: jjb: use same image in coverage publish job [integration/config] - 10https://gerrit.wikimedia.org/r/647194 (owner: 10Hashar) [21:50:27] (03CR) 10Jforrester: [C: 03+2] "Deployed." [integration/config] - 10https://gerrit.wikimedia.org/r/628589 (owner: 10Jforrester) [21:51:45] (03Merged) 10jenkins-bot: jjb: Provide PHP 7.3, 7.4, and 8.0 versions of PHPUnit coverage publish job [integration/config] - 10https://gerrit.wikimedia.org/r/628589 (owner: 10Jforrester) [21:58:37] (03PS1) 10Legoktm: php.go: Pass --no-scripts to composer for extra hardening [blubber] - 10https://gerrit.wikimedia.org/r/649738 (https://phabricator.wikimedia.org/T270207) [22:10:56] 10Release-Engineering-Team (Pipeline), 10MW-on-K8s, 10Operations, 10serviceops, 10Release Pipeline (Blubber): Deployment infrastructure for PHP microservices - https://phabricator.wikimedia.org/T261369 (10Legoktm) Have we ever run composer in production/part of an automated build process like this? For M... [22:29:11] (03PS1) 10Legoktm: Configure pipeline for mediawiki/libs/Shellbox [integration/config] - 10https://gerrit.wikimedia.org/r/649745 [22:30:20] (03CR) 10Legoktm: "I've never done this before, so I copy pasted from what I found in jjb/project-pipelines.yaml - let me know if that's wrong!" [integration/config] - 10https://gerrit.wikimedia.org/r/649745 (owner: 10Legoktm) [22:33:30] legoktm: Not sure shellbox needs custom jobs for this. [22:34:03] legoktm: It's fine, it's just extra config bloat. ;-) [22:34:06] me neither [22:34:22] I might've been looking in the wrong places but I couldn't find docs [22:34:26] (The generic job has a set of pipelines; if you want more/fewer/different, you need a custom job, otherwise it's the same.) [22:34:46] legoktm: https://wikitech.wikimedia.org/wiki/PipelineLib/Tutorial [22:35:04] More specifically, https://wikitech.wikimedia.org/wiki/PipelineLib/Guides/How_to_configure_CI_for_your_project [22:35:26] Though that ignores the generic option entirely, I see. :-) [22:35:57] that's exactly what I was looking for, ty [22:37:25] All kudos to m.arxarelli for brilliant documentation. [22:43:24] James_F: service-pipeline.yaml says the generic jobs are being deprecated in favor of project-specific jobs.. [22:43:48] Err. [22:43:50] They are? [22:43:53] That's news to me. [22:44:00] Does it say why? [22:44:54] 10Release-Engineering-Team (Pipeline), 10MW-on-K8s, 10Operations, 10serviceops, 10Release Pipeline (Blubber): Deployment infrastructure for PHP microservices - https://phabricator.wikimedia.org/T261369 (10Jdforrester-WMF) npm services build the whole of their (non-dev) npm dependency graph into the image... [22:46:49] 10Beta-Cluster-Infrastructure, 10Growth-Team (Current Sprint), 10User-Urbanecm: Create beta bnwiki - https://phabricator.wikimedia.org/T270165 (10Tgr) Thanks @Urbanecm! [22:46:57] 10Beta-Cluster-Infrastructure, 10Growth-Team (Current Sprint), 10User-Urbanecm: Create beta bnwiki - https://phabricator.wikimedia.org/T270165 (10Tgr) (Note the wiki does not have Growth features enabled ATM.) [22:50:16] James_F: maybe I'm misunderstanding https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/refs/heads/master/jjb/service-pipeline.yaml#39 [22:51:52] Maybe? It's not my call, and never was, so maybe that is the plan. [22:52:12] I generally prefer as little CI config as possible, using generics for everything, so there's less to fix when new things are wanted/things break. [22:54:55] James_F: we've been managing the per-project jenkins jobs via project templates, so there's no actual redundancy in the jjb job definitions themselves [22:55:06] legoktm: you're integration/config patch looks right to me [22:55:10] *your [22:56:06] you'll want a patch to your project before i merge that [22:56:12] marxarelli: `tox -e jenkins-jobs -- --conf jenkins_jobs.ini update ./jjb/ '*pipeline*'` updating two jobs instead of forty would be nice when we change that template, though? [22:56:33] i suppose :) [22:56:43] * James_F shrugs. [22:56:47] we haven't had an issue yet [22:56:49] marxarelli: ack, there's a patch pending right now, I expect we'll have it finalized in a few days [22:57:11] legoktm: Or just merge it now and accept that the repo will be unmergable until your patch is working. [22:57:23] legoktm: cool. sounds good [22:57:59] :p not ready to break the repo just yet [22:58:02] i saw your blubber patch, too. i'll have a look once i test and merge a recent regression fix for bd808 [22:58:28] legoktm: I mean, it's not like you're deploying it anywhere… ;-) [22:58:48] marxarelli: thanks :) [22:58:54] i thought we were deploying shellbox on friday before the break! :) [22:59:26] j/k of course [22:59:30] marxarelli: Psh, you're new here. On Sunday, *during* the break. Into prod. Somehow on buster despite being on k8s. [22:59:38] haha [22:59:43] that all sounds correct to me :) [23:00:17] bd808: We aren't meant to be encouraging the awarding of new I-broke-Wikipedia t-shirts [23:00:27] i thought we'd try out gnu/kfreebsd... [23:01:11] Not a Mach micro-kernel system transpiled into .NET runtime on Mono? [23:01:12] running ps3s? [23:01:21] *on* ps3s [23:01:35] A cluster of them. [23:02:11] get that synergistic processing power... [23:03:03] _j.oe_ shared a memory of ori setting up the icinga alert to tattle on himself for Sunday deploys earlier today. That put me in the nostalgic mood for doing it live. :) [23:03:15] Ha. [23:03:34] It's always Sunday somewhere! No, wait. [23:04:14] if RelEng would just take that pesky "Eng" off its name [23:04:22] that would really make things Great Again [23:04:56] Release Ineering? [23:05:07] :D [23:06:51] bd808: i'm testing your patch, and it seems to restore parity with the old implementation [23:07:16] I added a test for your exact case :) [23:07:42] The trick is whether the test tests reality or just the test system, though. [23:07:49] the fix was forehead slappingly dumb when I saw it [23:07:50] Not that I've ever been guilty of that. Oh no. [23:08:24] James_F: :) gaming 100% coverage was a sport at $DAYJOB-1 [23:08:38] like code golf only in fragile tests [23:09:30] bd808: I mean, https://doc.wikimedia.org/cover/?sort=cov exists for a reason, right? Humans are competitive animals. [23:09:53] (03CR) 10Dduvall: [C: 03+2] requirements: Fix regression in short form handling [blubber] - 10https://gerrit.wikimedia.org/r/648362 (https://phabricator.wikimedia.org/T263597) (owner: 10BryanDavis) [23:10:08] (03CR) 10Dduvall: [C: 03+2] "Thanks for the fix!" [blubber] - 10https://gerrit.wikimedia.org/r/648362 (https://phabricator.wikimedia.org/T263597) (owner: 10BryanDavis) [23:10:14] Though I feel a bit bad for Parsoid showing so poorly there, as most of their testing is integration testing, not encapsulated in the phpunit coverage metrics. [23:10:26] We ran a Jenkins plugin that made a literal game of who broke the build and who make the test coverage decrease [23:10:33] Ha. [23:10:52] GDS had something similar. [23:11:27] * bd808 sees that slimapp has worse coverage than core and feels shame [23:12:40] And of course https://doc.wikimedia.org/cover-extensions/?sort=cov with FlaggedRevs having 0% coverage feels true, so I just it completely, right? :-) [23:13:23] (03CR) 10jerkins-bot: [V: 04-1] requirements: Fix regression in short form handling [blubber] - 10https://gerrit.wikimedia.org/r/648362 (https://phabricator.wikimedia.org/T263597) (owner: 10BryanDavis) [23:13:51] so while we're on the topic of code coverage, if I want to entirely rewrite the logic of saving an edit, how much test coverage should there be? T157658 - my current WIP has 85% coverage [23:13:51] T157658: Factor out a backend from EditPage - https://phabricator.wikimedia.org/T157658 [23:14:50] DannyS712: 85% is quite impressive. [23:15:18] DannyS712: 100% would be nice for peace-of-mind (especially as we're likely to evolve it and be sure we're not breaking things), but… [23:15:33] DannyS712: its kind of subjective IMO. The important part is having tests that cover the core business logic and known edge cases. [23:15:56] branch coverage can be more important than LOC coverage in reality [23:15:57] Yeah. [23:16:17] It's a know-it-when-I-see-it thing. [23:16:38] I don't know how to get a coverage report to see what is and is not tested, its just the mwcore-phpunit-coverage-patch test result... [23:16:38] I'll probably upload a clean version for review this week (though if you want a sneak peak: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/647302) [23:16:44] 80-85% is a good naive target though I think [23:17:39] plus it inherits all of the integration tests for EditPage that already test the various quicks and edge cases [23:18:25] (03CR) 10Dduvall: [C: 03+2] requirements: Fix regression in short form handling [blubber] - 10https://gerrit.wikimedia.org/r/648362 (https://phabricator.wikimedia.org/T263597) (owner: 10BryanDavis) [23:19:13] bd808: odd. service checker failed during `helm test` but everything is working fine locally. hopefully it was just transient [23:20:38] so there is https://integration.wikimedia.org/ci/job/mwcore-phpunit-coverage-patch/23125/artifact/log/coverage.html created that shows changes to coverage from existing files, but why doesn't it show line coverage in the new files? [23:20:43] DannyS712: sonarcloud should tell you what's left to cover [23:21:11] (03Merged) 10jenkins-bot: requirements: Fix regression in short form handling [blubber] - 10https://gerrit.wikimedia.org/r/648362 (https://phabricator.wikimedia.org/T263597) (owner: 10BryanDavis) [23:21:22] oh indeed! [23:21:23] (03CR) 10Dduvall: [C: 03+1] "Looks good to me, but I'll give Jeena a chance to weight in since she implemented the composer support." [blubber] - 10https://gerrit.wikimedia.org/r/649738 (https://phabricator.wikimedia.org/T270207) (owner: 10Legoktm) [23:21:49] didn't think to look there; thanks [23:22:19] Where we renamed 'slaves' to 'replicas' but still have 'masters', what should they be called? [23:22:31] mutante: Masters. [23:22:41] replica_source :o [23:22:50] No. :-) [23:22:53] James_F: lol, ok [23:23:10] primary works too [23:23:11] https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1 [23:23:31] Some people have pushed renaming 'master' to 'primary', which I think is a bit meh. [23:24:13] good link thcipriani [23:24:15] Just putting it out there: [23:24:15] https://www.vice.com/en/article/8x7akv/masterslave-terminology-was-removed-from-python-programming-language [23:24:15] "One developer even invoked BDSM culture, saying “‘master/slave’ can have *positive* connotations. You want to support diversity, then why are you discriminating against that subculture?”" [23:24:33] There's always one. [23:24:52] primary is like the term from polyamourous scene [23:24:58] DannyS712: tbh I have a habit of ignoring test coverage anyway. I just know it's there as it's always fails for me. That's a plan for one day in the future to deal with tests on old code I've written (not MediaWiki). [23:25:09] inb4 let's not call our main DBs the doms, kthnxbai [23:27:03] maybe it should be more descriptive... role(gerrit::nobreak) role(gerrit::cangodown) [23:27:16] haha [23:27:18] gerrit::willbreakanywaybutohwell [23:28:31] gerrit primary is accurate. gerrit::writer might also be a helpful distinction since the replica doesn't accept writes. [23:28:48] ::writee, surely? [23:28:56] obviously [23:29:03] It's written to, as it were, not the one doing the writing. [23:29:10] You know, what makes me ask this in the first place is that I look at suggested code changes and we have a single role "gerrit" but then we do this stuff inside the role to make a difference "if this then that".. but honestly.. that is just 2 different roles.. so it should be 2 roles [23:29:20] Yeah. [23:29:49] i will be fine though with simply "gerrit" and "gerrit::replica" so we don't have to solve the naming one [23:30:11] * James_F grins. [23:30:19] also an acceptable alternative [23:31:16] in my memory there was one variable of difference between the two ... whatever it was that sets readonly [23:31:35] my memory and reality are frequently at odds [23:32:02] yea, but there is also the apache config and the vhost name in that [23:32:10] ah, right [23:32:11] and from there we get to https://gerrit.wikimedia.org/r/c/operations/puppet/+/643919 [23:32:37] and then I am like "before and after we do all this stuff inside the role... but in reality those are just servers with different roles" [23:34:12] also it's best to avoid the hieradata/hosts stuff where we edit .yaml named after specific physical machines [23:34:39] so I think "this should also be based on role.. if role is replica then host name is replica... done" [23:34:43] * thcipriani nods [23:35:37] getting rid of the heira hosts file seems like a reasonable goal [23:36:33] alright. thanks for the input. I will upload a change but now go out before the sun is setting so early again. [23:37:22] only another week or so of that [23:37:30] unless 2020 has more surprises in store [23:38:09] The thirteenth month of 2020 can't come swiftly enough. Oh. [23:38:15] well, correction, only another week of the sun setting earlier and earlier. many more months of darkness. (/^ヮ^)/*:・ﾟ✧ [23:38:16] yes:) the solstice is the original holiday [23:38:32] from there it's going up :) [23:38:39] Happy Yule, etc. [23:38:58] Merry Saturnalia [23:39:23] James_F: for the Anglo-Saxons https://en.wikipedia.org/wiki/M%C5%8Ddraniht [23:41:02] Huh. That was the New Year, a few days after Yule rather than on it? Odd. [23:42:21] maybe because it's "solstice followed by one week of party" and then fresh start, heh [23:43:29] don't like to link quora.. but https://www.quora.com/Why-doesnt-the-new-year-start-on-the-winter-solstice [23:44:51] not the most convincing answers though [23:56:19] question for the performance team before I go digging too deep: to reduce the size of the module registry (eg the fact that GuidedTour adds a new module for each tour), what about conditionally registering modules not just when they would work (i.e. dependency extension is installed) but also based on whether it would be used? Eg the [23:56:19] `mediawiki.special.unwatchedPages` module could only be registered when actually looking at Special:UnwatchedPages, and thus not add metadata to the module registry on other page views [23:57:07] DannyS712: That would fragment the RL cache on page titles. [23:57:31] The whole point is that the load.php call should be identical between pages so that users don't download it more than once. [23:57:51] oh :( [23:58:02] (Also the Perf team are in -perf, not here. :-)) [23:58:08] oops