[02:40:58] 10Continuous-Integration-Config, 10WMF-General-or-Unknown, 07Technical-Debt: Drop items we had in production/etc. for wikitech, like LdapAuthentication - https://phabricator.wikimedia.org/T376579#10351482 (10Jdforrester-WMF) [08:27:40] 06Release-Engineering-Team, 10MediaWiki-Core-Tests, 10Wikidata, 10wmde-wikidata-tech, and 4 others: Create a daily job running core + extension PHPUnit tests serially - https://phabricator.wikimedia.org/T372618#10351600 (10karapayneWMDE) a:05ArthurTaylor→03None [08:36:39] 10Scap, 06serviceops-radar, 06SRE: Confusing failed httpbb check for totoro.wikimedia.org during scap deployment - https://phabricator.wikimedia.org/T364880#10351622 (10Tgr) I ran into this twice today (not the totoro one specifically, just random testserver checks failing with an 503). Passed on the third r... [08:58:58] 10GitLab (CI & Job Runners), 06Release-Engineering-Team, 06collaboration-services, 10mwbot-rs: Random GitLab CI failures with ContainersNotReady - https://phabricator.wikimedia.org/T380680#10351658 (10Jelto) All jobs listed above have been executed on the Digital Ocean Cloud Runners. We had similar issues... [09:03:49] morning all! Would love to get some more feedback on https://phabricator.wikimedia.org/T372618 today if anyone has the time. Just to recap, I made some patches that seemed over-complicated. I modified the patches based on feedback, but it seems that the simplified version also won't work. So I'm considering reverting to the complicated version again (specifically the patches [09:03:49] https://gerrit.wikimedia.org/r/c/integration/config/+/1087458/5 and https://gerrit.wikimedia.org/r/c/integration/config/+/1088284 and https://gerrit.wikimedia.org/r/c/integration/config/+/1087442 ). Any guidance would be greatly appreciated - thanks! [09:10:28] (03PS3) 10Ilias Sarantopoulos: Revert "inference-services: remove llm CI pipeline jobs" [integration/config] - 10https://gerrit.wikimedia.org/r/1092874 [09:12:21] (03CR) 10CI reject: [V:04-1] Revert "inference-services: remove llm CI pipeline jobs" [integration/config] - 10https://gerrit.wikimedia.org/r/1092874 (owner: 10Ilias Sarantopoulos) [09:15:13] (03PS4) 10Ilias Sarantopoulos: Revert "inference-services: remove llm CI pipeline jobs" [integration/config] - 10https://gerrit.wikimedia.org/r/1092874 [09:54:24] hashar: https://gerrit.wikimedia.org/r/c/integration/config/+/1093909 should also be ready to go, afaict [10:00:20] kostajh: ahh that is great :) [10:00:32] (03CR) 10Hashar: [C:03+2] Enable PHPUnit parallel testing for mediawiki/core [integration/config] - 10https://gerrit.wikimedia.org/r/1093909 (https://phabricator.wikimedia.org/T379712) (owner: 10Arthur taylor) [10:00:41] codders: ^ :) [10:01:05] I have seen the change on early friday and was to afraid to turn it on before the week-en [10:01:06] d [10:01:06] hashar: yay! thanks :) let's see what explodes [10:01:10] fair [10:01:51] (03Merged) 10jenkins-bot: Enable PHPUnit parallel testing for mediawiki/core [integration/config] - 10https://gerrit.wikimedia.org/r/1093909 (https://phabricator.wikimedia.org/T379712) (owner: 10Arthur taylor) [10:02:22] !log Reloaded Zuul to enable PHPUnit parallel testing for mediawiki/core | https://gerrit.wikimedia.org/r/1093909 | T379712 [10:02:25] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [10:02:25] T379712: Run PHPUnit tests for mediawiki/core in parallel - https://phabricator.wikimedia.org/T379712 [10:02:26] hmm [10:02:41] now it is reloaded [10:04:11] thanks, will test it [10:13:18] 10Continuous-Integration-Infrastructure, 10Release-Engineering-Team (Seen), 06cloud-services-team, 10Cloud-VPS, 10ci-test-error (WMF-deployed Build Failure): Various CI jobs failing with: Could not resolve host: gerrit.wikimedia.org - https://phabricator.wikimedia.org/T374830#10352028 (10Nikerabbit)... [10:15:01] seems to be going ok so far [10:16:59] hashar: (in case you missed it) codders also needs some review/feedback/next steps for T372618 [10:17:00] T372618: Create a daily job running core + extension PHPUnit tests serially - https://phabricator.wikimedia.org/T372618 [10:28:01] (03CR) 10Hashar: [C:03+2] Revert "inference-services: remove llm CI pipeline jobs" [integration/config] - 10https://gerrit.wikimedia.org/r/1092874 (owner: 10Ilias Sarantopoulos) [10:29:12] 10Continuous-Integration-Infrastructure, 10Release-Engineering-Team (Seen), 06cloud-services-team, 10Cloud-VPS, 10ci-test-error (WMF-deployed Build Failure): Various CI jobs failing with: Could not resolve host: gerrit.wikimedia.org - https://phabricator.wikimedia.org/T374830#10352082 (10Nikerabbit) 05R... [10:29:20] codders / hashar: before parallel was enabled on core, wmf-quibble-core-vendor-mysql-php74 took 39 minutes. After, 11 minutes. [10:29:35] woo! that sounds like a pretty good result :) [10:29:58] :D [10:30:10] so running the PHPUnit test serially take ~ 30 minutes? [10:30:13] for just core? [10:30:18] oh no [10:30:22] it is running everything [10:30:40] (03Merged) 10jenkins-bot: Revert "inference-services: remove llm CI pipeline jobs" [integration/config] - 10https://gerrit.wikimedia.org/r/1092874 (owner: 10Ilias Sarantopoulos) [10:31:39] (03CR) 10Hashar: [C:03+2] "Deployed!" [integration/config] - 10https://gerrit.wikimedia.org/r/1092874 (owner: 10Ilias Sarantopoulos) [10:32:37] https://phabricator.wikimedia.org/T374830 - looks like it might be hurting gerrit a bit though [10:32:41] not sure if that's correlated [10:32:56] (03CR) 10Hashar: [C:03+2] build: Updating cross-spawn to 7.0.6 [integration/docroot] - 10https://gerrit.wikimedia.org/r/1094314 (owner: 10Libraryupgrader) [10:33:40] that is the resolver on WMCS which is failing [10:34:59] that is going on and off [10:39:48] 10Continuous-Integration-Infrastructure, 10Release-Engineering-Team (Seen), 06cloud-services-team, 10Cloud-VPS, 10ci-test-error (WMF-deployed Build Failure): Various CI jobs failing with: Could not resolve host: gerrit.wikimedia.org - https://phabricator.wikimedia.org/T374830#10352133 (10hashar) Those fa... [10:40:23] kostajh: yeah I would have to focus on that one [10:40:29] then I am not sure we have to run them serially [10:44:19] Project beta-code-update-eqiad build #523449: 04FAILURE in 1 min 19 sec: https://integration.wikimedia.org/ci/job/beta-code-update-eqiad/523449/ [10:45:17] 10Continuous-Integration-Infrastructure, 10Release-Engineering-Team (Seen), 06cloud-services-team, 10Cloud-VPS, 10ci-test-error (WMF-deployed Build Failure): Various CI jobs failing with: Could not resolve host: gerrit.wikimedia.org - https://phabricator.wikimedia.org/T374830#10352159 (10Lucas_Werkmeister... [11:20:50] (03update) 10hashar: scap clean: delete branches as gerrit_push_user [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/481 (https://phabricator.wikimedia.org/T218783) [11:24:09] (03merge) 10hashar: scap clean: delete branches as gerrit_push_user [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/481 (https://phabricator.wikimedia.org/T218783) [11:25:33] (03open) 10hashar: Release 4.128.0 [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/597 [11:27:33] (03merge) 10hashar: Release 4.128.0 [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/597 [11:35:18] Error response from daemon: manifest for docker-registry.wikimedia.org/repos/releng/scap/buster:4.128.0 not found: manifest unknown: manifest unknown [11:35:21] * hashar whistles [11:35:32] I will check after lunch [11:47:27] * hashar had to wait for some Dockerimage to be built [11:58:55] 10Continuous-Integration-Infrastructure, 07Jenkins, 06Release-Engineering-Team: Stop using the tox-buster image for CI - https://phabricator.wikimedia.org/T380730 (10Joe) 03NEW [12:16:49] (03CR) 10Cmelo: [C:03+1] "LGTM!" [integration/config] - 10https://gerrit.wikimedia.org/r/1094459 (https://phabricator.wikimedia.org/T380595) (owner: 10Daimona Eaytoy) [13:14:22] 10Release-Engineering-Team (Seen), 10Scap: `scap clean` failure: SSH Too many authentication failures: 7 - https://phabricator.wikimedia.org/T218783#10352826 (10hashar) [13:14:24] 14Release-Engineering-Team (Deployment Autopilot 🛩ī¸), 10Scap: Allow Scap to push to Gerrit without operator creds - https://phabricator.wikimedia.org/T306425#10352827 (10hashar) [13:18:36] 10Release-Engineering-Team (Seen), 10Scap: `scap clean` failure: SSH Too many authentication failures: 7 - https://phabricator.wikimedia.org/T218783#10352844 (10hashar) 05Open→03Resolved a:03hashar I have deployed the scap patch and ran: ` mkdir /srv/mediawiki-staging/php-1.39.0-wmf.1 && scap clean -... [13:26:02] 10Continuous-Integration-Config, 10Continuous-Integration-Infrastructure: Migrate all CI jobs from buster to bullseye or later and drop buster testing support - https://phabricator.wikimedia.org/T335765#10352904 (10hashar) [13:26:03] 10Continuous-Integration-Infrastructure, 07Jenkins, 06Release-Engineering-Team: Stop using the tox-buster image for CI - https://phabricator.wikimedia.org/T380730#10352907 (10hashar) →14Duplicate dup:03T335765 [13:39:15] 10Release-Engineering-Team (Priority Backlog đŸ“Ĩ): Delete wmf branches from Gerrit repositories - https://phabricator.wikimedia.org/T303828#10353010 (10hashar) After having fixed T218783 (via T306425), `scap clean --delete-gerrit-branch 1.39.0-wmf.1` fails: ` name=scap clean --delete-gerrit-branch 1.44.0-wmf.2 13... [13:55:01] (03PS2) 10Jforrester: Docker: [php84] Upgrade to 8.4.1 with full set of extensions, provide Quibble [integration/config] - 10https://gerrit.wikimedia.org/r/1094458 [13:55:13] (03open) 10hashar: scap clean: first delete branch from superproject [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/598 (https://phabricator.wikimedia.org/T303828) [13:55:54] (03CR) 10Jforrester: [C:03+2] Docker: [php84] Upgrade to 8.4.1 with full set of extensions, provide Quibble [integration/config] - 10https://gerrit.wikimedia.org/r/1094458 (owner: 10Jforrester) [13:57:45] (03Merged) 10jenkins-bot: Docker: [php84] Upgrade to 8.4.1 with full set of extensions, provide Quibble [integration/config] - 10https://gerrit.wikimedia.org/r/1094458 (owner: 10Jforrester) [13:58:07] !log Docker: [php84] Upgrade to 8.4.1 with full set of extensions, provide Quibble [13:58:08] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [14:00:19] yay [14:02:08] (03PS1) 10Jforrester: Docker: Also actually git add mediawiki-phan-php84 [integration/config] - 10https://gerrit.wikimedia.org/r/1097385 [14:02:09] (03PS1) 10Jforrester: jjb: Update php84 jobs to 8.4.1, provide Quibble ones [integration/config] - 10https://gerrit.wikimedia.org/r/1097386 [14:02:20] (03CR) 10Jforrester: [C:03+2] Docker: Also actually git add mediawiki-phan-php84 [integration/config] - 10https://gerrit.wikimedia.org/r/1097385 (owner: 10Jforrester) [14:03:52] (03update) 10hashar: scap clean: first delete branch from superproject [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/598 (https://phabricator.wikimedia.org/T303828) [14:04:05] (03Merged) 10jenkins-bot: Docker: Also actually git add mediawiki-phan-php84 [integration/config] - 10https://gerrit.wikimedia.org/r/1097385 (owner: 10Jforrester) [14:07:38] !log lucaswerkmeister-wmde@integration-castor05:~$ rm -r /srv/castor/castor-mw-ext-and-skins/master/mwext-node18-rundoc/_cacache-nuked-2024-11-06-delete-later/ # clean up [14:07:39] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [14:11:35] !log lucaswerkmeister-wmde@integration-castor05:~$ sudo -u jenkins-deploy rm -rf /srv/castor/castor-mw-ext-and-skins/master/wmf-quibble-selenium-php74/ # wipe castor cache to fix failure seen in https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php74/41800/ [14:11:36] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [14:13:37] Hmmmmm. I can't run jjb-update any more? "No module named 'packaging.requirements'". I hate Python. [14:16:38] OK, fixed again. [14:23:55] (03PS2) 10Jforrester: jjb: Update php84 jobs to 8.4.1, provide Quibble ones [integration/config] - 10https://gerrit.wikimedia.org/r/1097386 [14:25:53] (03PS3) 10Jforrester: jjb: Update php84 jobs to 8.4.1, provide Quibble ones [integration/config] - 10https://gerrit.wikimedia.org/r/1097386 [14:27:21] (03CR) 10Jforrester: [C:03+2] jjb: Update php84 jobs to 8.4.1, provide Quibble ones [integration/config] - 10https://gerrit.wikimedia.org/r/1097386 (owner: 10Jforrester) [14:29:01] (03Merged) 10jenkins-bot: jjb: Update php84 jobs to 8.4.1, provide Quibble ones [integration/config] - 10https://gerrit.wikimedia.org/r/1097386 (owner: 10Jforrester) [14:30:03] (03PS1) 10Jforrester: Zuul: Configure experimental php84 for Quibble etc. [integration/config] - 10https://gerrit.wikimedia.org/r/1097396 [14:33:36] James_F: my guess is you use a recentish python? [14:34:05] * hashar today I have learned about https://devguide.python.org/versions/ [14:34:09] hashar: It's because Python is a moving target and everything about the ecosystem is broken on random versions. It reminds me strongly of Vue. :-( [14:34:50] well [14:35:00] the world has long shifted toward continuously releasing [14:35:12] with shorten support [14:35:47] Indeed. [14:37:23] (03CR) 10Jforrester: [C:03+2] Zuul: Configure experimental php84 for Quibble etc. [integration/config] - 10https://gerrit.wikimedia.org/r/1097396 (owner: 10Jforrester) [14:37:26] git submodule foreach bash -c 'git branch -r --list "origin/wmf/1*"|egrep -v "origin/wmf/1.44"|sed -e "s%origin/%:%" || :' | egrep -v '^Entering '|wc -l [14:37:26] 41639 [14:37:27] eek [14:37:41] hashar: Bon chance. [14:38:35] (03Merged) 10jenkins-bot: Zuul: Configure experimental php84 for Quibble etc. [integration/config] - 10https://gerrit.wikimedia.org/r/1097396 (owner: 10Jforrester) [14:45:09] Reedy: First CI run against MW-core has the two open tasks failures, but also some others: https://integration.wikimedia.org/ci/job/mediawiki-quibble-vendor-mysql-php84/1/console [14:47:19] I think most of those are known/filed [14:47:24] the net_url2 one isn't [14:47:43] "Use of TestDeprecatedClass::$privateDeprecated was deprecated in MediaWiki 1.24" is new, isn't it? [14:48:25] well, it's been there since 1.24 ;P [14:49:10] we also run in phpunit in parallel now :) [14:52:14] !log Manually deleting old wmf branches before wmf/1.44.0-wmf.1 # T303828 [14:52:17] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [14:52:17] T303828: Delete wmf branches from Gerrit repositories - https://phabricator.wikimedia.org/T303828 [14:58:30] I am missing maxsem as a releaser https://gerrit.wikimedia.org/g/mediawiki/core/+/refs/tags/1.25.6 [14:58:40] `I iz ugh` [14:58:56] Quite. [14:59:05] :d [14:59:08] :D even [15:01:06] and [15:18:21] !log Deleted old release branch of mediawiki/core and replaced them with signed tag (affecting REL1_23 to REL1_38) [15:18:23] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [15:21:48] hashar: I'd be willing to try rename project. We can delete the new project, and rename the old one. I have a local clone to re-force push the new repo in case it goes wrong. Will this change old changesets to be assocaited with the new project name? [15:22:24] or will they remain associated with the old name? [15:22:27] e.g. a change set like https://gerrit.wikimedia.org/r/c/analytics/statsv/+/721044 [15:25:15] (03update) 10jnuche: Fix scap install-world -l behavior [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/586 (https://phabricator.wikimedia.org/T380418) (owner: 10dancy) [15:32:16] !log Deleted old fundraising branches fundraising/REL1_27 fundraising/REL1_31 and fundraising/REL1_35 from mediawiki/core and mediawiki/vendor [15:32:17] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [15:33:51] Krinkle: I have no idea :-) [15:34:04] but I think they will be attached to the new name [15:34:11] so that link https://gerrit.wikimedia.org/r/c/analytics/statsv/+/721044 will be broken [15:34:27] in favor of the new name ( performance/statsv ) [15:37:03] then in Phabricator, the links point to https://gerrit.wikimedia.org/r/721044 [15:37:13] and those would continue to work [15:40:14] (03merge) 10hashar: scap clean: first delete branch from superproject [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/598 (https://phabricator.wikimedia.org/T303828) [15:45:14] hashar: cool, yeah, sure! [15:51:26] It looks like I have permission to delete repos but not rename repos [15:55:18] hmm [15:55:28] oh they are different plugins [15:59:33] (03PS1) 10Hashar: Review access change [All-Projects] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/1097425 [16:00:00] (03PS2) 10Hashar: Grant "Rename project" to "Administrators" [All-Projects] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/1097425 (https://phabricator.wikimedia.org/T239693) [16:00:10] (03CR) 10Hashar: [V:03+2 C:03+2] Grant "Rename project" to "Administrators" [All-Projects] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/1097425 (https://phabricator.wikimedia.org/T239693) (owner: 10Hashar) [16:01:17] oh [16:01:30] of course there is web UI implemented [16:01:38] there is NO web ui [16:01:39] bh [16:05:15] Krinkle: I guess I can try though some change were made to the performance/statsv repo [16:06:57] !log gerrit: renamed performance/statsv to performance/statsv-back [16:06:58] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [16:07:12] !log gerrit: renamed analytics/statsv to performance/statsv [16:07:13] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [16:09:09] yeah the old changes are showing with the new name: https://gerrit.wikimedia.org/r/q/project:performance/statsv [16:09:25] Krinkle: I did the rename [16:10:05] the two new changes are at https://gerrit.wikimedia.org/r/q/project:performance/statsv-back [16:10:15] and would need to be proposed again for performance/statsv [16:15:02] I have pasted the outputs at T380767 [16:15:03] T380767: Rename analytics/statsv to performance/statsv - https://phabricator.wikimedia.org/T380767 [16:17:30] (03open) 10hashar: Release 4.129.0 [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/599 [16:19:30] (03merge) 10hashar: Release 4.129.0 [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/599 [16:31:02] Project beta-update-databases-eqiad build #80633: 04FAILURE in 11 min: https://integration.wikimedia.org/ci/job/beta-update-databases-eqiad/80633/ [16:39:10] ^ 16:31:02 wikimedia/parsoid: 0.21.0-a8 installed, 0.21.0-a7 required. [16:39:10] :) [16:39:18] which should be transient [16:40:31] (03update) 10jnuche: Fix scap install-world -l behavior [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/586 (https://phabricator.wikimedia.org/T380418) (owner: 10dancy) [16:40:46] (03approved) 10jnuche: Fix scap install-world -l behavior [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/586 (https://phabricator.wikimedia.org/T380418) (owner: 10dancy) [16:42:36] (03merge) 10jnuche: Fix scap install-world -l behavior [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/586 (https://phabricator.wikimedia.org/T380418) (owner: 10dancy) [16:44:52] (03update) 10jnuche: Fix scap install-world -l behavior [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/586 (https://phabricator.wikimedia.org/T380418) (owner: 10dancy) [16:55:08] 06Project-Admins: Description #community-consensus-needed is contradictory to common practices - https://phabricator.wikimedia.org/T380763#10354286 (10Pppery) There were 16 tasks in #community-consensus-needed not also in #wikimedia-site-requests: https://phabricator.wikimedia.org/project/board/175/?filter=u3MDz... [17:00:52] !log Deleted wmf/1.44.0-wmf.2 branch using `scap clean --delete-gerrit-branch 1.44.0-wmf.2` # T303828 [17:00:54] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [17:00:54] T303828: Delete wmf branches from Gerrit repositories - https://phabricator.wikimedia.org/T303828 [17:01:10] !log Manually deleted wmf/1.44.0-wmf.1 branch from MediaWiki repositories # T303828 [17:01:13] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [17:02:02] I hate puppet really [17:02:03] well [17:02:15] the X layers of inception involved to understand what is going on [17:02:18] is my concern :b [17:02:40] Mon *-*-* 21:00:00 America/Los_Angeles [17:02:41] :/ [17:13:53] oh that is thanksgiving [17:15:52] hashar: Thank you for deleting all those old branches. [17:16:08] E.g. https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/VisualEditor/+refs is so much shorter now. [17:16:21] yeah I wanted to do that for some time [17:16:29] Also wow, https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/VisualEditor/+/refs/tags/wmf/1.25wmf24 I suppose was manual? [17:16:34] I also replaced some REL branches with tags instead [17:16:37] on mediawiki/core [17:16:38] I saw. [17:16:45] and really [17:17:05] what ever process we have to make a releasebranch obsolete/EOL should convert the branch to a tag [17:17:07] on all repos [17:17:21] but I don't know whether that is automatized [17:17:53] I think R.eedy does *some* automated stuff for the EOL announcement, but mostly it's manual. [17:18:10] * hashar starts an Ansible playbook [17:18:34] that VE tag, well I don't know [17:18:40] I am not sure whether Gerrit keeps an audit log [17:18:51] s/keeps/kept/ [17:23:45] James_F: I have deleted the tag [17:23:51] Merge "Update VE core for cherry-pick" into wmf/1.25wmf24 [17:24:10] that was a merge of I1a6c75d0cb43c2387919bb3734a5fd7f2f90bcea [17:24:25] that was probably a mistake [17:26:33] FIRING: DatasourceError: Queue (Jenkins jobs + Zuul functions) - https://grafana.wikimedia.org/alerting/grafana/b9a8470a-ebab-46f7-9be2-22b5e74a528b/view - https://wikitech.wikimedia.org/wiki/Monitoring/DatasourceError - https://alerts.wikimedia.org/?q=alertname%3DDatasourceError [17:31:04] Yippee, build fixed! [17:31:04] Project beta-update-databases-eqiad build #80634: 09FIXED in 11 min: https://integration.wikimedia.org/ci/job/beta-update-databases-eqiad/80634/ [17:31:33] RESOLVED: DatasourceError: Queue (Jenkins jobs + Zuul functions) - https://grafana.wikimedia.org/alerting/grafana/b9a8470a-ebab-46f7-9be2-22b5e74a528b/view - https://wikitech.wikimedia.org/wiki/Monitoring/DatasourceError - https://alerts.wikimedia.org/?q=alertname%3DDatasourceError [17:58:18] kostajh: I can't wait to see what that parallel build test change does for the wall clock runtime of the `wmf/next` image. The git tagging there goes through gate-and-submit with it's historic 40 minute runtime. Cutting gate-and-submit down to ~11 minutes should cut the full pipeline time in half! [18:00:32] Ah that would be nice if it works out. [18:00:54] What process builds wmf/next? (Not familiar with that image) [18:01:21] do we run tests for the wmf/next image? [18:01:30] i mean, we already know the set of changes passed in master [18:01:41] so when marked with wmf/next the same set should still work [18:01:46] same as we do for the wmf branches [18:02:11] (they are blindly cut without running tests) [18:02:32] kostajh: it is built on the releases-jenkins server. The best docs at the moment are at https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Group_-1#[WE6.2.1]_Publish_pre-train_single_version_containers [18:03:21] hashar: we actually test the wmf/* branches via gate-and-submit these days too. That has been the case since the branch cut moved to Jenkins. [18:04:13] ahhh [18:04:20] my mental broken of what is running when is broken :b [18:05:08] Arguably there are things this tests that have never been tested in combination before. Every week there are extensions and skins that did not get any code changes. Aso changes to core do not trigger testing of everything else. [18:05:31] those tests are not run [18:05:45] looks like the commit is eg https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1075093 [18:05:54] which targets mediawiki/core and the extensions tests are not run [18:06:07] though we do run the tests for the extensions that are part of wmf-quibble [18:06:30] I am wondering if those commit have ever failed [18:06:42] cause they should always pass as far as tests are involved [18:07:16] anyway, it is working as is [18:09:57] hashar: I did 'git remote update' on my existing clone, which interpreted it as a "force push" to HEAD~2. I then simply ran 'git review' on my existing checkout, which then proposed two new changesets with identical commit hash for me to merge. [18:10:14] Thanks! [18:10:36] awesome [18:11:08] that is the first repo to ever have been renamed [18:12:02] I do note that, unlike GitHub/GitLab, it does not store any kind of back-compat alias. E.g. Gitiles (HTTPS) doesn't redirect or alias, and git clone / git fetch also 404s for the old URL. [18:12:12] That's fine for this trivial one, but something to consider for anything more prominent. [18:12:29] :o repo rename? we have the technology? [18:12:40] well we always had [18:12:53] it is as easy as `mv old.git new.git` on disk [18:13:07] the devil is dealing with all the aftermath of a renaming :) [18:13:17] but yes [18:13:21] we can now rename repos [18:13:23] "easily" [18:15:27] I am off for dinner, I will try to find a SRE later tonight to get a puppet merge of https://gerrit.wikimedia.org/r/c/operations/puppet/+/1097444 [18:15:35] In some sense, it's almost better to archive the old repo and force-push the new repo, because that way all old CR urls remain the same. On the other hand, it's also useful in some sense to be able to use Gerrit search without needing awareness of the old name. [18:15:38] and wmf/ branches will then be auto deleted again \o/ [18:15:58] either way, old change-Ids are clickable and resolvable in Gerrit. [18:16:17] maybe we can set some redirects in Apache [18:16:34] but for cases where a bad name is determined early on, it's neat to be able to rename and have CR pages come along automatically. [18:16:35] but if they are unlikely to be of any use, I am willing to ignore that [18:16:48] yeah.. [18:17:01] I wonder if/when Gerrit is planning to have change numbers not be globally unique. [18:17:21] I don't now what are Google plans :) [18:17:31] as long as they are, it shoudl be trivial to have Gerrit automatically redirect /r/whatever/123 to r/current-name/123 [18:17:38] the same way it already does for /r/123 [18:17:49] but alas that's not a thing yet. [18:19:40] I am off for dinner: [18:24:25] !log gerrit: changed parent of `performance/statsv` to `performance` (was `analytics`) # T380767 [18:24:28] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [18:24:28] T380767: Rename analytics/statsv to performance/statsv - https://phabricator.wikimedia.org/T380767 [18:24:33] so yeah there are some glitches to look at [18:24:43] * hashar dines [19:01:56] 06Project-Admins: Description #community-consensus-needed is contradictory to common practices - https://phabricator.wikimedia.org/T380763#10354980 (10Urbanecm) >>! In T380763#10354286, @Pppery wrote: > However, I disagree with the premise here entirely - the usage of the #community-consensus-needed tag means so... [19:05:26] 06Project-Admins: Description #community-consensus-needed is contradictory to common practices - https://phabricator.wikimedia.org/T380763#10354991 (10Urbanecm) >>! In T380763#10354217, @Frostly wrote: > I completely agree that community consensus is not necessarily needed just because someone objects, but I als... [19:18:15] (03CR) 10Kgraessle: [C:03+1] Zuul: [mediawiki/extensions/PageTriage] Add PageViewInfo dependency [integration/config] - 10https://gerrit.wikimedia.org/r/1094569 (https://phabricator.wikimedia.org/T207238) (owner: 10Rockingpenny4) [19:45:06] 06Project-Admins: Description #community-consensus-needed is contradictory to common practices - https://phabricator.wikimedia.org/T380763#10355092 (10AntiCompositeNumber) This is really an engineering management problem, not a project management problem. WMF engineering management processes should prevent softw... [20:06:15] 06Project-Admins: Description #community-consensus-needed is contradictory to common practices - https://phabricator.wikimedia.org/T380763#10355173 (10Pppery) > I believe those cases should be split to an implementation task and a deployment task. That way, the consensus tag can still keep a well defined purpose... [20:36:40] FIRING: [2x] DatasourceNoData: - https://alerts.wikimedia.org/?q=alertname%3DDatasourceNoData [20:46:40] RESOLVED: [2x] DatasourceNoData: - https://alerts.wikimedia.org/?q=alertname%3DDatasourceNoData [22:39:13] (03PS1) 10Abaris: zuul/layout.yaml Add mediawiki/libs/Message [integration/config] - 10https://gerrit.wikimedia.org/r/1097539 (https://phabricator.wikimedia.org/T227447)