[00:17:25] (03PS1) 10Jforrester: jjb: [wikidata-query-gui-build] Drop for now, awaiting replacement with Docker [integration/config] - 10https://gerrit.wikimedia.org/r/575381 (https://phabricator.wikimedia.org/T210286) [00:18:09] (03CR) 10Jforrester: [C: 03+2] jjb: [wikidata-query-gui-build] Drop for now, awaiting replacement with Docker [integration/config] - 10https://gerrit.wikimedia.org/r/575381 (https://phabricator.wikimedia.org/T210286) (owner: 10Jforrester) [00:18:30] !log jjb: Deleting wikidata-query-gui-build [00:18:31] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [00:19:15] (03Merged) 10jenkins-bot: jjb: [wikidata-query-gui-build] Drop for now, awaiting replacement with Docker [integration/config] - 10https://gerrit.wikimedia.org/r/575381 (https://phabricator.wikimedia.org/T210286) (owner: 10Jforrester) [00:20:05] 10Continuous-Integration-Config, 10Release-Engineering-Team (CI & Testing services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10JavaScript: Upgrade all CI jobs from node6/npm3 to node10/npm6 across all projects - https://phabricator.wikimedia.org/T211784 (10Jdforrester-WMF) [00:21:15] 10Continuous-Integration-Infrastructure (Slipway), 10Release-Engineering-Team (CI & Testing services), 10Release-Engineering-Team-TODO, 10Wikidata, and 3 others: Migrate wikidata-query-gui-build to Docker containers - https://phabricator.wikimedia.org/T210286 (10Jdforrester-WMF) [00:21:17] 10Continuous-Integration-Infrastructure (phase-out-jessie), 10Release-Engineering-Team (CI & Testing services), 10Release-Engineering-Team-TODO, 10Patch-For-Review: Delete Jenkins label DebianJessie - https://phabricator.wikimedia.org/T239981 (10Jdforrester-WMF) [00:21:19] 10Continuous-Integration-Config, 10Release-Engineering-Team (CI & Testing services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10JavaScript: Upgrade all CI jobs from node6/npm3 to node10/npm6 across all projects - https://phabricator.wikimedia.org/T211784 (10Jdforrester-WMF) [00:28:37] 10Continuous-Integration-Infrastructure: Please install 'npx' node package runner - https://phabricator.wikimedia.org/T246400 (10Demian) [00:29:30] 10Continuous-Integration-Infrastructure: Please install 'npx' node package runner on CI nodes - https://phabricator.wikimedia.org/T246400 (10Demian) [00:47:44] James_F: is T237773 something that I could entice you to help think about and move forward? [00:47:45] T237773: Move Wikitech onto the production MW cluster - https://phabricator.wikimedia.org/T237773 [00:48:42] bd808: Totally. [00:49:06] Moving the DBs over seems the hardest step. [00:49:25] Can we do the DBs first and then the hardware, or is it too magical? [00:49:52] Also, could we fake it by re-creating the wiki from a dump as `wikitechwiki` and having it co-opt the URLs? [00:50:32] That would make things a great deal simpler, but the cut-over might mean some data was lost, so we'd have to lock the wiki for a bit before the switchover. [00:50:36] I think it would be possible to move the db with the mediawiki still running from labweb*, but it would take new firewall holes [00:50:51] Right. [00:50:54] locking for a switch is a-ok [00:51:07] Most of the read/write is now moved to Horizon, right? [00:51:24] OpenStack no longers cares about Wikitech at all [00:51:30] Excellent. [00:51:31] and vice versa [00:51:43] their only connection is the LDAP directory [00:52:29] the db rename is a thing that some folks care about. if we could accomplish that it might at least reduce confusion in the shared config [00:52:43] but I think that is low priority as a feature [00:53:40] we have an existing process to update wikitech-static's content via dumps though, so if loading from a dump made that easy then +1 for doing it [00:54:19] that is also a way we could do a soft launch in parallel and cut the proper host name over after everything is green [00:55:59] A.nderw, R.eedy, and I have done most of the things to make wikitech less of a snowflake that can be done without taking this jump into the main cluster [00:56:13] so I think its time to JFDI [00:57:45] Loading from a dump risks random things just going missing. [00:58:03] If access through the firewall was a hard no, we'd do that (and take advantage to rename). [00:58:10] But if we can avoid it, let's do that. [00:58:21] And people can whine about the DB in their own time. :-) [00:58:33] it could also be done with a couple rounds of db dump/import [00:58:45] Main and catch-up? Yeah, maybe. [00:59:01] that's how we have moved the db 3 times before [00:59:07] Eesh. [00:59:14] as it has floated around from host to host [00:59:14] Well, on the plus side we know that works. [01:00:27] it has never been completely clear to me where the dbname gets embedded in the content such that renaming is hard [01:00:42] It probably doesn't. [01:00:59] The number one risk is ES, but you're not using that right now? [01:01:12] I'm pretty sure we are not [01:01:16] And for wikitech, the main special-snowflake risk would be the static dump. [01:01:34] Changing the DB name after you start using ExternalStorage is going to be Hard™, however. [01:01:41] Sorry, ES means two things. [01:01:50] we did the move that put all the local media in swift quite a while ago, so that part is handled [01:01:56] Nice. [01:02:06] Don't /think/ swift cares about dbname. [01:02:31] no, it's a bucket name there that the wiki needs to know [01:02:37] Right. [01:02:42] swift has no idea that mediawiki is using it [01:03:10] module some weird routing stuff for thumbnail creation [01:03:14] *modulo [01:03:41] although that even may be in another layer after all the work that Gilles did for Thumbor [01:05:59] Because it's complexity all the way down. [01:06:38] I haven't made the sticker (yet), but I think MediaWiki's motto should be "It all about edge cases!" [01:06:56] * James_F grins. [01:07:05] Maybe with a drawing of a bunch of rusty knives? [01:07:47] or a pin pricking a thumb and a big drop of blood :) [01:07:52] * James_F grins. [01:09:01] bd808: Oh! Can we remove MergeUser from wikitech now, then? [01:09:18] uhhh.. probably? [01:09:37] OK, will look at that one again. [01:09:48] Know that I've got a two-year-old patch waiting for people able to re-disable it. :-) [01:10:23] I haven't used it for a long time. There may be a some outstanding "please change my Develouer account name" requests that could need it, but nobody has worked on any of those since Chad left really [01:10:32] Ah. [01:10:56] He and I were going to finally script all that, but then he jumped out the window [01:11:47] Making the wiki an SUL wiki is going to be hard. [01:11:55] (I've mostly run away from doing that for Governance wiki.) [01:13:55] yeah, its a big lift. And still quite blocked on a replacement LDAP account creation tool [01:14:13] "Maybe next year" ;) [01:14:20] Maybe 3020. [01:15:14] I have a hunch that a while after I shed my manager duties I will rediscover a desire to write code on the weekends [01:15:22] * James_F laughs. [01:15:33] burnout is real and I've got it [01:16:37] Striker has a lot of the code that would be needed for a stand-alone LDAP account manager tool [01:17:01] it is however cheating by using API access to Wikitech to do hard things like TilteBlacklist [01:17:10] *TitleBlacklist [01:17:40] So we would need to decide if that is actually a feature or needs to be reinvented [01:18:43] Anyway, thanks for being interested James_F. I will try to keep this conversation moving in fits and starts. [01:18:51] Excellent. [01:18:57] * James_F hugs bd808 for being awesome. [01:19:12] aww. you can't say nice thins to an engineer :) [01:19:59] Hmm. Does wikitech not have an i18n build eviction step? [01:20:10] [[MediaWiki:Group-shell]] is magically both defined and not defined. [01:20:14] Which is… novel. [01:20:30] Suggests that the OSM i18n build is still floating around, but ISTR we killed that. [01:20:54] Oh, right, we're still loading it? [01:21:04] Eh, never mind. [01:22:53] James_F: yeah. OSM has been reduced to doing very little, but it is still needed [01:23:05] it mostly is a config layer over LDAPAuth now [01:23:27] But `group-shell` isn't defined in en.json. [01:26:21] oh yeah [01:26:41] we need to rip out that group in the config actually. There is a task about that [01:26:56] Yeah, I'm doing it. :-) [01:30:41] bd808: Do you still use the 'contentadmin' user group? [01:30:53] (03PS1) 10Dduvall: pipeline: Prevent running of containers with arbitrary image refs [integration/pipelinelib] - 10https://gerrit.wikimedia.org/r/575389 [01:33:55] (03CR) 10Dduvall: [C: 03+2] pipeline: Prevent running of containers with arbitrary image refs [integration/pipelinelib] - 10https://gerrit.wikimedia.org/r/575389 (owner: 10Dduvall) [01:34:37] (03Merged) 10jenkins-bot: pipeline: Prevent running of containers with arbitrary image refs [integration/pipelinelib] - 10https://gerrit.wikimedia.org/r/575389 (owner: 10Dduvall) [01:39:02] James_F: yes [01:39:13] OK, will leave that one alone. [01:39:23] contentadmin is sysop without the ability to edit site js basically [01:39:38] Isn't that sysop nowadays? [01:39:40] and that is needed on wikitech for WBp:BEANS reasons [01:39:49] Only interfaceadmins can edit site JS. [01:40:00] Because, indeed, of WP:BEANS reasons. [01:40:22] oh, right. That's pretty new. Yeah we should figure out if that can happen on wikitech too then [01:40:42] * James_F nods. [01:40:49] sysop on wikitech right now CAN edit site js [01:40:57] Ooh, ouch. [01:41:27] which is why if you look at the sysop list they are all current staff or former staff [01:41:39] Filed as T246405 [01:41:39] T246405: On wikitech, make sysops unable to edit site JS, and then retire contentadmin - https://phabricator.wikimedia.org/T246405 [01:51:59] 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10Patch-For-Review, 10Release, 10Train Deployments: 1.35.0-wmf.21 deployment blockers - https://phabricator.wikimedia.org/T233869 (10Jdforrester-WMF) 05Open→03Resolved [03:56:28] 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10Security-Team, 10Patch-For-Review, and 2 others: Wikimedia deployers audit - https://phabricator.wikimedia.org/T237696 (10Samwilson) I've not deployed for a long time, and not often ever, however... [04:10:07] 10Phabricator (Search), 10Release-Engineering-Team (Development services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10User-MModell, 10User-brennen: Make search context highlights work with the ferret search engine - https://phabricator.wikimedia.org/T230787 (10mmodell) [04:13:14] 10Phabricator (Search), 10Release-Engineering-Team (Development services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10User-MModell, 10User-brennen: Make search context highlights work with the ferret search engine - https://phabricator.wikimedia.org/T230787 (10mmodell) @brennen: I've su... [07:50:58] PROBLEM - App Server Main HTTP Response on deployment-mediawiki-07 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [07:55:47] RECOVERY - App Server Main HTTP Response on deployment-mediawiki-07 is OK: HTTP OK: HTTP/1.1 200 OK - 92788 bytes in 1.113 second response time [09:12:59] 10Release-Engineering-Team (Pipeline), 10Analytics, 10Analytics-Kanban, 10Release Pipeline, and 2 others: Migrate EventStreams to k8s deployment pipeline - https://phabricator.wikimedia.org/T238658 (10akosiaris) No it's not full. CPU and memory usage requests are barely at 10%. events have been cleared fro... [09:16:06] PROBLEM - Parsoid on deployment-parsoid09 is CRITICAL: connect to address 172.16.5.63 and port 8000: Connection refused [09:16:06] PROBLEM - Parsoid on deployment-mediawiki-parsoid10 is CRITICAL: connect to address 172.16.0.141 and port 8000: Connection refused [09:21:35] 10Beta-Cluster-Infrastructure, 10Chinese-Sites: Request for right on zh Beta Cluster - https://phabricator.wikimedia.org/T246201 (10Sunny00217) >>! In T246201#5919535, @Aklapper wrote: > @Sunny00217: Hi, which specific right are you requesting? Is this about `interface-admin`, or is this about something else?... [09:35:00] PROBLEM - Free space - all mounts on deployment-snapshot01 is CRITICAL: CRITICAL: deployment-prep.deployment-snapshot01.diskspace._data.byte_percentfree (No valid datapoints found)deployment-prep.deployment-snapshot01.diskspace.root.byte_percentfree (<10.00%) [09:45:00] RECOVERY - Free space - all mounts on deployment-snapshot01 is OK: OK: deployment-prep.deployment-snapshot01.diskspace._data.byte_percentfree (No valid datapoints found) [10:17:28] 10Beta-Cluster-Infrastructure, 10Chinese-Sites: Request for sysop right on zh Beta Cluster for Sunny00217 - https://phabricator.wikimedia.org/T246201 (10Aklapper) [10:53:20] 10Phabricator: Minor UI glitch in task Subscribers field: Unneeded large space at beginning of a line - https://phabricator.wikimedia.org/T246434 (10Aklapper) p:05Triage→03Lowest [10:54:24] 10Phabricator, 10Browser-Support-Firefox: Minor UI glitch in task Subscribers field: Unneeded large space at beginning of a line - https://phabricator.wikimedia.org/T246434 (10Aklapper) [10:58:47] 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO, 10DBA, 10Epic: Implement a system to automatically deploy schema changes without needing DBA intervention - https://phabricator.wikimedia.org/T121857 (10jcrespo) [11:20:31] 10Phabricator, 10Browser-Support-Firefox: Minor UI glitch in task Subscribers field: Unneeded large space at beginning of a line - https://phabricator.wikimedia.org/T246434 (10Schnark) Looks like an issue with floating layout and increased line-height by the CJK characters. [11:35:02] 10Gerrit, 10User-Sebastian_Berlin-WMSE: Jenkins-bot won't merge patch - https://phabricator.wikimedia.org/T246436 (10Sebastian_Berlin-WMSE) [11:52:25] 10Phabricator, 10Browser-Support-Firefox: Minor UI glitch in task Subscribers field: Unneeded large space at beginning of a line - https://phabricator.wikimedia.org/T246434 (10Aklapper) Oh yay, you saw a pattern that I didn't see! Good catch, thanks! [11:53:15] 10Phabricator, 10Browser-Support-Firefox: Firefox: Minor UI glitch in task Subscribers field: Unneeded space at beginning of a line if previous line included CJK characters - https://phabricator.wikimedia.org/T246434 (10Aklapper) [11:56:38] 10Gerrit, 10User-Sebastian_Berlin-WMSE: Jenkins-bot won't merge patch - https://phabricator.wikimedia.org/T246436 (10Mainframe98) Could it be that the change needs rebasing? It looks like its [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikispeech/+/573569 | ancestor ]] is set to patchset 3, while... [12:24:39] 10Release-Engineering-Team (Pipeline), 10Release-Engineering-Team-TODO, 10ChangeProp, 10Release Pipeline, and 3 others: Migrate changeprop to kubernetes - https://phabricator.wikimedia.org/T213193 (10hnowlan) [12:40:24] !log Migrated https://github.com/wikimedia/mediawiki-extensions-NearbyPages to Gerrit; GitHub repo now watches the Gerrit one [12:40:26] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [12:48:59] 10Beta-Cluster-Infrastructure, 10Operations, 10observability, 10serviceops, 10Patch-For-Review: Stream a subset of mediawiki apache logs to logstash - https://phabricator.wikimedia.org/T244472 (10jijiki) [12:49:37] 10Beta-Cluster-Infrastructure, 10Operations, 10observability, 10serviceops, 10Patch-For-Review: Stream a subset of mediawiki apache logs to logstash - https://phabricator.wikimedia.org/T244472 (10jijiki) 05Open→03Resolved Thank you @herron and @fgiunchedi for your help! [12:51:07] 10Continuous-Integration-Config: Add extension-NearbyPages to zuul - https://phabricator.wikimedia.org/T246437 (10MarcoAurelio) [13:17:30] 10Gerrit, 10User-Sebastian_Berlin-WMSE: Jenkins-bot won't merge patch - https://phabricator.wikimedia.org/T246436 (10Sebastian_Berlin-WMSE) 05Open→03Resolved a:03Sebastian_Berlin-WMSE Thanks, @Mainframe98. After a bit of struggle I managed to rebase properly and the patch merged. [13:30:02] 10Deployments, 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10serviceops, and 3 others: Cache of wmf-config/InitialiseSettings often 1 step behind - https://phabricator.wikimedia.org/T236104 (10LarsWirzenius) I admit I don't understand PHP or... [13:50:10] 10Phabricator: "AphrontDuplicateKeyQueryException" when trying to drag a task from (sub-project) column to other column on parent workboard - https://phabricator.wikimedia.org/T139396 (10Aklapper) Has anyone still experienced this in the last 18 months? If not I'm probably just going to decline this... [13:56:33] 10Deployments, 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10serviceops, and 3 others: Cache of wmf-config/InitialiseSettings often 1 step behind - https://phabricator.wikimedia.org/T236104 (10Krinkle) >>! In T236104#5926376, @LarsWirzenius w... [14:01:21] 10Deployments, 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10serviceops, and 3 others: Cache of wmf-config/InitialiseSettings often 1 step behind - https://phabricator.wikimedia.org/T236104 (10Krinkle) I'm wondering if it'd be easier if we si... [14:41:09] 10Scap, 10Operations, 10serviceops: Make canary wait time configurable - https://phabricator.wikimedia.org/T217924 (10jijiki) Great we merged this patch! Do we have a plan of how we will communicate this to the deployers when we release scap as well as how to test that it is all good in production? Thahnk you! [14:42:21] 10Deployments, 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10serviceops, and 3 others: Cache of wmf-config/InitialiseSettings often 1 step behind - https://phabricator.wikimedia.org/T236104 (10LarsWirzenius) Okay, there's clearly things here... [14:49:03] 10Deployments, 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10serviceops, and 3 others: Cache of wmf-config/InitialiseSettings often 1 step behind - https://phabricator.wikimedia.org/T236104 (10Joe) >>! In T236104#5926454, @Krinkle wrote: > I'... [15:33:40] I feel like “the requested URL returned error: 502” errors in CI builds (when cloning various repositories from Gerrit) have become more common lately [15:33:46] is that a known issue or something? [15:33:50] example at https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php72-docker/22953/console [15:57:29] Lucas_WMDE: unsure if there is a bug open for it, but I think I can say I have seen it a bit more recently too. Especially for projects which do not get a lot of commits. [15:58:03] 10Beta-Cluster-Infrastructure, 10MediaWiki-API, 10Pywikibot, 10Core Platform Team Workboards (Clinic Duty Team), and 2 others: Attempt to login fails several times - https://phabricator.wikimedia.org/T224712 (10Dvorapa) It first failed in May 29th after https://github.com/wikimedia/pywikibot/commit/893d03f... [16:04:22] 10Scap, 10Operations, 10serviceops: Make canary wait time configurable - https://phabricator.wikimedia.org/T217924 (10LarsWirzenius) I had a discussion with Tyler just now. We plan the following: * add to docs/ in the source tree; this ends up in doc.wikimedia.org * add to debian/changelog in the source tre... [16:09:08] (03PS1) 10MarcoAurelio: [NearbyPages] Register with CI [integration/config] - 10https://gerrit.wikimedia.org/r/575563 (https://phabricator.wikimedia.org/T246437) [16:09:59] 10Scap, 10Operations, 10serviceops: Make canary wait time configurable - https://phabricator.wikimedia.org/T217924 (10jijiki) >>! In T217924#5926912, @LarsWirzenius wrote: > I had a discussion with Tyler just now. We plan the following: > > * add to docs/ in the source tree; this ends up in doc.wikimedia.or... [16:21:24] 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)): Make scap release with --canary-wait-time and integration test changes - https://phabricator.wikimedia.org/T246455 (10LarsWirzenius) [16:22:02] 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)): Make scap release with --canary-wait-time and integration test changes - https://phabricator.wikimedia.org/T246455 (10LarsWirzenius) p:05Triage→03Medium [16:32:16] PROBLEM - Work requests waiting in Zuul Gearman server on contint1001 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [150.0] https://www.mediawiki.org/wiki/Continuous_integration/Zuul https://grafana.wikimedia.org/dashboard/db/zuul-gearman?panelId=10&fullscreen&orgId=1 [16:56:14] (03CR) 10Jdlrobson: [C: 03+1] [NearbyPages] Register with CI [integration/config] - 10https://gerrit.wikimedia.org/r/575563 (https://phabricator.wikimedia.org/T246437) (owner: 10MarcoAurelio) [17:02:07] 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10Security-Team, 10Patch-For-Review, and 2 others: Wikimedia deployers audit - https://phabricator.wikimedia.org/T237696 (10sbassett) >>! In T237696#5925494, @Samwilson wrote: > I've not deployed fo... [17:07:40] RECOVERY - Work requests waiting in Zuul Gearman server on contint1001 is OK: OK: Less than 100.00% above the threshold [90.0] https://www.mediawiki.org/wiki/Continuous_integration/Zuul https://grafana.wikimedia.org/dashboard/db/zuul-gearman?panelId=10&fullscreen&orgId=1 [17:17:58] (03PS1) 1020after4: Add the very dangerous --delete argument to mass delete branches [tools/release] - 10https://gerrit.wikimedia.org/r/575571 [17:18:44] (03CR) 10jerkins-bot: [V: 04-1] Add the very dangerous --delete argument to mass delete branches [tools/release] - 10https://gerrit.wikimedia.org/r/575571 (owner: 1020after4) [17:20:17] (03PS1) 10CRusnov: Edit Project Config [software/netbox] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/575572 [17:21:06] (03Abandoned) 10CRusnov: Edit Project Config [software/netbox] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/575572 (owner: 10CRusnov) [17:29:47] (03PS1) 1020after4: change train-deploy-notes branch regex and files [integration/config] - 10https://gerrit.wikimedia.org/r/575575 [17:32:03] (03CR) 10MarcoAurelio: "Question: does NearbyPages depends on, or requires having MobileFrontend? Thanks." [integration/config] - 10https://gerrit.wikimedia.org/r/575563 (https://phabricator.wikimedia.org/T246437) (owner: 10MarcoAurelio) [17:32:41] (03CR) 10Jdlrobson: [C: 03+1] "No MobileFrontend dependency necessary." [integration/config] - 10https://gerrit.wikimedia.org/r/575563 (https://phabricator.wikimedia.org/T246437) (owner: 10MarcoAurelio) [17:32:46] (03CR) 10Jforrester: [C: 03+1] change train-deploy-notes branch regex and files (031 comment) [integration/config] - 10https://gerrit.wikimedia.org/r/575575 (owner: 1020after4) [17:32:50] (03CR) 10Jdlrobson: [C: 03+1] "it will be standalone" [integration/config] - 10https://gerrit.wikimedia.org/r/575563 (https://phabricator.wikimedia.org/T246437) (owner: 10MarcoAurelio) [17:34:34] (03CR) 10Jforrester: [C: 04-1] [NearbyPages] Register with CI (031 comment) [integration/config] - 10https://gerrit.wikimedia.org/r/575563 (https://phabricator.wikimedia.org/T246437) (owner: 10MarcoAurelio) [17:37:33] James_F: NearbyPages is still in experimental status afaik, not sure if we want to add phan/seccheck now? [17:37:43] not in prod/not deployed yet [17:39:04] (03CR) 1020after4: [C: 03+1] "lgtm and tyler says +2" [tools/scap] - 10https://gerrit.wikimedia.org/r/573298 (https://phabricator.wikimedia.org/T245614) (owner: 10Lars Wirzenius) [17:39:27] hauskatze: If it's not going to production, you've put it in the wrong section. [17:39:40] that might be correct [17:39:56] quick fix incoming [17:40:04] If it is likely to go to prod, then we should put in phan right from the start. [17:40:14] It's much easier to start with it than try to add it later. [17:40:36] Jdlrobson is its author. I guess we could ask him [17:41:07] Easy fix any case; either move it or add extension-{phan,seccheck} [17:59:09] Hi! Quick question if I could... Do you know what would 'unstable' result mean in this jenkins job https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php72-docker/48903/console ? [17:59:19] Build step 'Publish JUnit test result report' changed build result to UNSTABLE [18:05:11] Sounds like there's some extra stuff in the xml [18:37:48] Lucas_WMDE: i'm getting that same CI error for a WBMI patch. does it usually resolve on a recheck for you? [18:41:16] 10Continuous-Integration-Config, 10phan: Set up real CI for mediawiki/tools/phan - https://phabricator.wikimedia.org/T226117 (10Umherirrender) It seems the new job cannot use the caches with all other CI jobs. Currently all packages are downloaded on each run https://integration.wikimedia.org/ci/job/mw-tools-... [18:48:33] 10Continuous-Integration-Config, 10phan: Set up real CI for mediawiki/tools/phan - https://phabricator.wikimedia.org/T226117 (10Daimona) >>! In T226117#5927540, @Umherirrender wrote: > It seems the new job cannot use the caches with all other CI jobs. Currently all packages are downloaded on each run > > http... [18:49:14] 10Deployments, 10Release-Engineering-Team (Deployment services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10serviceops, and 3 others: Cache of wmf-config/InitialiseSettings often 1 step behind - https://phabricator.wikimedia.org/T236104 (10Jdforrester-WMF) >>! In T236104#5926454, @Krinkle... [19:00:26] 10Continuous-Integration-Config, 10phan: Set up real CI for mediawiki/tools/phan - https://phabricator.wikimedia.org/T226117 (10Umherirrender) Another fix of cache was https://gerrit.wikimedia.org/r/#/c/integration/config/+/501867/3/jjb/mediawiki.yaml There is a `docker-cache-dir` in the list of builders, on... [19:06:13] (03PS2) 1020after4: Add the very dangerous --delete argument to mass delete branches [tools/release] - 10https://gerrit.wikimedia.org/r/575571 [19:06:39] (03CR) 10jerkins-bot: [V: 04-1] Add the very dangerous --delete argument to mass delete branches [tools/release] - 10https://gerrit.wikimedia.org/r/575571 (owner: 1020after4) [19:17:59] (03CR) 1020after4: "retest" [tools/release] - 10https://gerrit.wikimedia.org/r/575571 (owner: 1020after4) [19:21:41] (03PS1) 10Daimona Eaytoy: jjb: add cache dir for phan-testrun [integration/config] - 10https://gerrit.wikimedia.org/r/575600 (https://phabricator.wikimedia.org/T226117) [19:23:03] (03PS3) 1020after4: Add the very dangerous --delete argument to mass delete branches [tools/release] - 10https://gerrit.wikimedia.org/r/575571 [19:25:24] 10Gerrit, 10Release-Engineering-Team (Development services), 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10User-brennen: Clean old wmf branches in Gerrit - https://phabricator.wikimedia.org/T244368 (10brennen) a:05thcipriani→03brennen [19:29:22] (03CR) 1020after4: change train-deploy-notes branch regex and files (031 comment) [integration/config] - 10https://gerrit.wikimedia.org/r/575575 (owner: 1020after4) [19:37:03] !log in process of deleting many old branches for T244368 [19:37:05] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [19:37:05] T244368: Clean old wmf branches in Gerrit - https://phabricator.wikimedia.org/T244368 [19:37:29] Gosh. [19:37:35] brennen: Fingers crossed. [19:38:06] (03CR) 10Jforrester: "> Patch Set 2:" [tools/release] - 10https://gerrit.wikimedia.org/r/575571 (owner: 1020after4) [19:42:44] James_F: paired with tyler on a janky shell script. seems to be working well enough. [19:43:26] * James_F crosses fingers anywawy. [20:00:26] !log finished deleting wmf/1.34.0-wmf.* branches for T244368 [20:00:29] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [20:00:29] T244368: Clean old wmf branches in Gerrit - https://phabricator.wikimedia.org/T244368 [20:01:52] \o/ [20:25:11] 10Project-Admins: Create Project: Section-Name-Diff - https://phabricator.wikimedia.org/T246484 (10ifried) [20:27:57] 10Project-Admins: Create Project: Named-References-VE - https://phabricator.wikimedia.org/T246485 (10DannyS712) [20:29:32] 10Project-Admins: Create Project: Named-References-VE - https://phabricator.wikimedia.org/T246485 (10Jdforrester-WMF) Sub-project of the existing #visualeditor-mediawiki-references, I assume? [20:36:50] 10Project-Admins: Create Project: Named-References-VE - https://phabricator.wikimedia.org/T246485 (10DannyS712) >>! In T246485#5927916, @Jdforrester-WMF wrote: > Sub-project of the existing #visualeditor-mediawiki-references, I assume? Note that the references project would then be a parent project, which canno... [21:17:40] 10Continuous-Integration-Config, 10NearbyPages, 10Patch-For-Review: Add extension-NearbyPages to zuul - https://phabricator.wikimedia.org/T246437 (10Jdlrobson) [23:37:22] 10Release-Engineering-Team-TODO (2020-01 to 2020-03 (Q3)), 10Release Pipeline: Review pipelinelib reference documentation - https://phabricator.wikimedia.org/T246253 (10dduvall) a:05dduvall→03None The [[ https://wikitech.wikimedia.org/wiki/PipelineLib/Reference | reference documentation on Wikitech ]] shou...