[00:09:54] 10MediaWiki-Releasing, 10MW-1.37-notes, 10MW-1.37-release: Release 1.37.0-rc.0 - https://phabricator.wikimedia.org/T289591 (10Jdforrester-WMF) [00:11:39] logstash-beta is now not loading at all. Not sure if related to its domain changing from wmflabs to wmcloud [00:11:52] It used to load the interface at least but have no MW data [00:12:06] ref T233134 etc [00:12:06] T233134: logstash-beta.wmflabs.org does not receive any mediawiki events - https://phabricator.wikimedia.org/T233134 [00:22:15] (03CR) 10Subramanya Sastry: "looks like the new gerrit is particular about 'unresolved comments' and adds clutter ... so going in and clearing that up now." [integration/visualdiff] - 10https://gerrit.wikimedia.org/r/712848 (owner: 10Subramanya Sastry) [03:44:23] (03CR) 10Krinkle: npm: Use cache for npm ci and prefer offline (031 comment) [integration/quibble] - 10https://gerrit.wikimedia.org/r/702909 (https://phabricator.wikimedia.org/T211705) (owner: 10Kosta Harlan) [04:26:31] 10Release-Engineering-Team (Doing), 10Release, 10Train Deployments: 1.38.0-wmf.1 deployment blockers - https://phabricator.wikimedia.org/T281165 (10Majavah) The branch cut seems to have happened for the wrong branch (1.37.0-wmf.24): https://gerrit.wikimedia.org/r/c/mediawiki/core/+/722480/ [04:59:24] 10Release-Engineering-Team (Doing), 10Release, 10Train Deployments: 1.38.0-wmf.1 deployment blockers - https://phabricator.wikimedia.org/T281165 (10DannyS712) >>! In T281165#7367712, @Majavah wrote: > The branch cut seems to have happened for the wrong branch (1.37.0-wmf.24): https://gerrit.wikimedia.org/r/c... [07:14:03] (03PS1) 10Robert Vogel: Remove dependencies to BlueSpice* extensions [integration/config] - 10https://gerrit.wikimedia.org/r/722545 [08:14:29] 10Continuous-Integration-Config, 10Release-Engineering-Team: Rebuild CI images affected by OpenSSL compat issue with new Let's Encrypt issuance chain - https://phabricator.wikimedia.org/T291425 (10MoritzMuehlenhoff) The expected version numbers are openssl1.0: 1.0.2u-1~deb9u5 gnutls28: 3.5.8-5+deb9u6 [08:29:32] 10Continuous-Integration-Infrastructure, 10wdwb-tech, 10Browser-Tests, 10User-Addshore, 10User-zeljkofilipin: Centrally look for flakey browser tests - https://phabricator.wikimedia.org/T277205 (10Addshore) [08:29:34] 10Continuous-Integration-Infrastructure, 10wdwb-tech, 10Browser-Tests, 10User-Addshore, 10User-zeljkofilipin: Centrally look for flakey browser tests - https://phabricator.wikimedia.org/T277205 (10Addshore) [09:50:53] 10Continuous-Integration-Config, 10Release-Engineering-Team (Next), 10Wikibase (3rd party installations), 10Wikidata, and 3 others: Move some Wikibase selenium tests to a standalone job - https://phabricator.wikimedia.org/T287582 (10Addshore) I have a suspicion that we would not want to split out `client/d... [09:56:59] 10Continuous-Integration-Config, 10Wikidata, 10Wikidata-Campsite, 10wdwb-tech, 10User-awight: Migrate Wikibase selenium tests to Quibble+Apache, enable concurrency - https://phabricator.wikimedia.org/T291476 (10awight) [09:58:02] hashar: ^ :-) [10:02:39] 10Continuous-Integration-Config, 10Wikidata, 10Wikidata-Campsite, 10wdwb-tech, 10User-awight: Migrate Wikibase selenium tests to Quibble+Apache, enable concurrency - https://phabricator.wikimedia.org/T291476 (10awight) [11:13:31] 10Release-Engineering-Team (Radar), 10Quality-and-Test-Engineering-Team (QTE), 10serviceops-radar, 10CommRel-Specialists-Support (Jul-Sep-2021), and 2 others: Expand the list of group 1 wikis to contain at least one (preferably 2) smaller "top ten size" wikis - https://phabricator.wikimedia.org/T286664 (10E... [12:54:28] awight: looks like a good `.plan` [13:10:30] just tried gitlab, really nice! Smooth creation of first repo [13:55:00] Is it possible to inject Semantic MediaWiki as a phan dependency in CI? https://gerrit.wikimedia.org/g/integration/config/+/68df8e0ccf38bf7f2ca3b2c7cb025228624858c9/zuul/parameter_functions.py#488 [13:55:40] Askin because the extension is hosted on github, and I don't know if there's a way to change the clone URL for zuul per-element [13:56:47] Daimona: You can probably composer require it too [13:56:52] * Reedy barfs a little [13:57:31] Heh, lol, been thinking about that as a last resort [13:57:55] I can imagine cloning random repos from random places isn't probably something we really want to support [13:58:04] 10Release-Engineering-Team (Doing), 10Scap, 10serviceops: Deploy Scap version 4.0.0 - https://phabricator.wikimedia.org/T291095 (10jijiki) Thank @dancy, I will try to get it done this week with @Arnoldokoth [13:58:08] But I think it wouldn't work well for basically anything except phan [13:58:36] Yeah totally, I was hoping e.g. for a WMF-hosted mirror of some sort, or maybe a special case somewhere [13:59:47] Which random extension we host has some dependancy on SMW? [14:01:15] Context is https://phabricator.wikimedia.org/T228155 [14:02:49] I guess there might be others, especially given that for phan we need to include optional dependencies [14:14:21] Daimona: the whole logic is based on Gerrit repos layout so nop. But might work if fetched via composer, I think we had a Phan variant using composer to install dependencies [14:14:56] or you can add stubs, but if the repo depends heavily on SemanticMediaWiki I guess that defeat the purpose [14:15:00] of phan [14:15:28] Got it, merci [14:15:40] then I am not sure we have a phan job processing composer [14:15:41] It heavily depends on SMW, so I'm just going to disable a bunch of related issues [14:15:45] or maybe the job always run composer install [14:15:49] no clue really :-\ [14:16:08] I'd rather not use composer because I don't feel comfortable with that hack [14:19:07] checked, jenkins uses the macro docker-setup-mwext-for-phan which runs quibble to clone the repository [14:19:20] and get dependencies running --packages-source=vendor [14:19:46] so that clones mediawiki/vendor rather than merging all composer.json via the merge plugin and running composer install from mw root [14:19:56] oh [14:20:47] and dev dependencies are intentionally not fetched (`quibble --no-deps`) [14:22:38] but we still run `composer update` from the extension/skin directory to get phan config in [14:22:46] so I guess you can abuse that system to add semantic mediawiki in [14:24:52] So that would be via composer, right? [14:27:39] Daimona: yup [14:27:42] it is a bit of a hack though [14:28:16] Yeah, it is [14:28:53] Daimona: the "logic" is https://github.com/wikimedia/integration-config/blob/master/jjb/macro-docker.yaml#L166-L197 [14:28:58] there are some comments [14:29:20] so we blindly `composer update` fetching whatever is defined there and I am guessing dev dependencies as well [14:29:23] Reading that, thanks [14:29:46] Yeah, I don't see a --no-dev [14:29:51] so we might have code relying on dev dependency which would not be detected by phan. Ideally we would solely install the phan-comfig dev dependencies [14:29:57] but that is a different problem really [14:30:18] maybe if you add semantic mediawiki to dev dependencies that would fit for the phan job [15:37:38] 10Release-Engineering-Team (Doing), 10GitLab, 10Privacy Engineering, 10Security-Team, 10SecTeam-Processed: Add "Samuel (WMF)" account to Security Team group in gitlab.wikimedia.org - https://phabricator.wikimedia.org/T291094 (10sbassett) [15:45:58] dduvall, hashar: Oops, the branch cut tool cut it as 1.37.0-wmf.24 not 1.38.0-wmf.1. [15:46:32] oy [15:47:28] I can fix the run for next time trivially, but… [15:47:51] I guess we could re-cut? [15:48:39] James_F: might as well re-cut [15:48:41] !log Updated the releases-jenkins automatic branch cut job to make 1.38.0 branches (missed ahead of T281165) [15:48:43] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [15:48:44] T281165: 1.38.0-wmf.1 deployment blockers - https://phabricator.wikimedia.org/T281165 [15:49:34] !log Re-running the branch cut job for T281165 [15:49:37] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [15:49:50] Ha, sorry dduvall, I'll hands-off and leave it to you. :-) [15:50:17] Do we want to delete the 1.37.0-wmf.24 branch? [15:51:12] yes [15:51:18] Want me to do that? [15:51:21] i'll do that :) [15:51:24] Cool. [15:51:36] Also we should convert our old branches to tags at some point. [15:51:55] thanks for spotting the issue! [15:52:46] ahem, https://phabricator.wikimedia.org/T281165#7367712 [15:54:05] Ah, you spotted it too, nice. :-) [15:54:15] 10Continuous-Integration-Config, 10MediaWiki-extensions-Page_Forms, 10Patch-For-Review: Add phan to PageForms - https://phabricator.wikimedia.org/T228155 (10Daimona) a:05Yaron_Koren→03Daimona [15:54:20] I found it from the whines from ReleaseTaggerBot not finding wmf.25 (because wmf.24 existed). [15:55:58] 10Release-Engineering-Team: Delete the wmf/1.37.0-wmf.* branches once we've fully deployed to 1.38.0-wmf.1 and finished with them - https://phabricator.wikimedia.org/T291501 (10Jdforrester-WMF) [15:56:25] dduvall: https://releases-jenkins.wikimedia.org/job/Automatic%20branch%20cut/74/console failed. :-( [15:56:47] * James_F steps back. [15:58:23] hmm, not sure. i'll have a look [15:58:53] we started the re-cut at the exact same time and i aborted when i noticed you'd started it too. maybe there was a race condition [15:59:01] Yeah. [15:59:33] i'll delete both 1.37.0-wmf.24 and 1.38.0-wmf.1 branches and start it again [15:59:37] Cool. [16:04:33] !log deleting wmf/1.37.0-wmf.24 and wmf/1.38.0-wmf.1 branches due to the branch cut job gone awry [16:04:34] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [16:06:22] does branch creation support a timestamp (e.g. last night?) [16:06:31] No,. [16:06:40] Nor a git hash. [16:06:42] I recall there being some difficulty with that last time we tried for e.g. REL branch fixups [16:06:59] I think people are assuming though that stuff after the bot ran is not going to be deployed [16:07:02] Yes, hence why I manually did the REL1_37 branch cut seconds after the wmf.23 cut last week. [16:08:41] maybe no train this week then [16:08:49] What? Yes train this week. [16:09:05] When this has happened before, we've just sent out a quick note that the branch point has changed. [16:09:28] by the time realistically that that has been understood and reacted to, it'll be Thursday [16:09:37] If you (a) merge really risky stuff right after the branch point but (b) don't actually check what the branch point is, you're writing bad code. [16:09:55] you mean like how we remove stuff from master after the rel branches are cut? :D [16:10:02] I think this is expected, and the train cut is also logged in SAL [16:10:22] Yes, but I *check* that the REL branch cut went correctly first. [16:10:25] I don't see the cut on https://sal.toolforge.org/ [16:10:44] Indeed, the cut is manually logged as part of the test group deploy process. [16:11:09] So the log to the SAL is and would have been in our future even if it had gone correctly. [16:11:55] "03:06 <•wikibugs> (PS1) TrainBranchBot: Branch commit for wmf/1.37.0-wmf.24 [core] (wmf/1.37.0-wmf.24) - https://gerrit.wikimedia.org/r/722480" [16:11:59] this was sent in -operations last night [16:12:10] Oh, it logs to that channel, right. [16:12:34] New stuff since I last ran the train. :-) [16:12:46] Anyway, as you've pointed out, there's no SAL entry for wmf.1 being cut. [16:13:02] anyway, I think it's a testament to our reliability that people generlaly don't check. We can hold a survey but I'm pretty sure most people know that when they start work on Tuesday, the branch has been cut. [16:13:20] and an evern smaller percentage will notice the number it [16:13:57] anyway, we can link to the weekly changelog in the mail goaround for people to check anything that shouldn't be there yet. [16:16:58] Thanks to the bot creating https://www.mediawiki.org/wiki/MediaWiki_1.37/wmf.24/Changelog we can even diff it against https://www.mediawiki.org/wiki/MediaWiki_1.38/wmf.1/Changelog when that exists. [16:21:03] Project beta-update-databases-eqiad build #53381: 04FAILURE in 1 min 1 sec: https://integration.wikimedia.org/ci/job/beta-update-databases-eqiad/53381/ [16:26:51] !log deleted wmf/1.37.0-wmf.24 and wmf/1.38.0-wmf.1 branches due to a branch cut job gone awry. re-running job to cut wmf/1.38.0-wmf.1 (T281165) [16:26:54] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [16:26:54] T281165: 1.38.0-wmf.1 deployment blockers - https://phabricator.wikimedia.org/T281165 [16:32:22] i'm realizing now that i could have just created 1.38.0-wmf.1 at the same commit as 1.37.0-wmf.24 :/ [16:35:13] hashar: any thoughts on this? ^ tl;dr the branch cut mistakenly created 1.37.0-wmf.24 last night instead of 1.38.0-wmf.1. i've now deleted 1.37.0-wmf.24 and am re-running the branch-cut job to create 1.38.0-wmf.1 at current remote HEADs [16:35:28] (03Abandoned) 10Jforrester: jjb: Switch OOJS jobs using php-ast to images with ast 1.0.14 [integration/config] - 10https://gerrit.wikimedia.org/r/719138 (owner: 10Daimona Eaytoy) [16:36:06] however, i have the output of `gerrit ls-projects --show-branch wmf/1.37.0-wmf.24` saved and could conceivably delete wmf/1.38.0-wmf.1 and re-create it at the previous commits of wmf/1.37.0-wmf.24 [16:37:20] and possibly hack the branch-cut job to re-run using wmf/1.38.0-wmf.1 as the version. i'm not sure if that will fail when it attempts to create the branch, or just skip that part due to the branch already existing [16:37:53] twentyafterfour: ^ do you happen to know? [16:38:01] James_F, Krinkle: thoughts? [16:38:18] I think it'd probably be easier to just proceed as now? [16:38:38] The drift won't be huge, probably? Eh. If you can 'trivially' re-create wmf.1 as wmf.24 maybe do so. [16:39:03] But we're already halfway through Tuesday without even pushing it onto test wikis. [16:39:09] dduvall: aye, right because it supports 'master' it can also support wmf.24 as the static start, that seems neat yeah [16:39:23] well, wmf.24 is gone now sadly [16:39:33] The script doesn't work very well in branchpoint-based branching. [16:39:35] but i have the shas for each project where it used to be [16:39:39] moment of silence for wmf.24 [16:39:43] haha [16:39:45] Or at least, didn't for REL1_36 etc. hence all the issues. [16:40:14] I think with the page diff james mentioned, we'd have a pretty solid email to write perhaps even copy in the diff if its small enough [16:40:28] alrighty [16:40:30] Well, we'd need the ReleaseNotesBot to run. [16:40:48] I thought that was done by https://releases-jenkins.wikimedia.org/job/Automatic%20branch%20cut/ but clearly not. [16:40:58] we have a make changelog py script, which I'm guessing this invokes? [16:41:05] Yeah, I'll just do it manually. [16:41:05] * Krinkle can't see the job nor its output [16:41:07] One sec. [16:42:34] it's a separate job for release notes https://integration.wikimedia.org/ci/job/train-deploy-notes/ [16:42:50] because... reasons. we had the release notes job first :) [16:43:43] it should run on postmerge [16:43:44] James_F: ^ [16:44:08] Ah, OK, I'll stand down. :-) [16:44:26] I guess it's a different job because previously the creation and merge were many hours apart? [16:44:48] creation was not yet automated [16:44:58] Ah, even older ago, yeah. [16:59:32] And here's the branch notes diff: https://www.mediawiki.org/w/index.php?diff=4819281&oldid=4818542 [17:21:47] Yippee, build fixed! [17:21:48] Project beta-update-databases-eqiad build #53382: 09FIXED in 1 min 46 sec: https://integration.wikimedia.org/ci/job/beta-update-databases-eqiad/53382/ [17:22:18] 10Release-Engineering-Team (Doing), 10GitLab, 10User-brennen: runner-1002 is out of space - https://phabricator.wikimedia.org/T291221 (10brennen) cc: @dduvall ` brennen@runner-1002:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 18G 0 18G 0% /dev tmpfs 3.6G 374... [17:23:36] brennen: a `docker system prune -af` should tidy that up for now [17:24:28] adding a cronjob to the profile is a better long-term solution [17:24:48] once a day is probably frequent enough [17:25:20] What does `docker system df` report before the cleanup? [17:26:20] https://www.irccloud.com/pastebin/IoXxBwt4/ [17:27:21] Hmm. I wonder what's in those volumes. [17:28:19] caches it seems [17:28:22] e.g. `runner-bffzzv-project-40-concurrent-0-cache-3c3f060a0374fc8bc39395164f415a70` [17:29:04] Hrm.. lack of gc detected! [17:30:03] that one seems to be empty... [17:30:22] will docker volume ls give me sizes? maybe i need inspect [17:32:42] https://www.irccloud.com/pastebin/53I5vul3/ [17:33:02] (from root@runner-1002:/var/lib/docker/volumes# du -hs * | sort -h) [17:34:14] ah, yeah `docker system df -v` is nicer [17:34:25] https://www.irccloud.com/pastebin/6QsL7iaC/ [17:34:30] one of the bigger ones [17:34:57] 20GB ain't what it used to be [17:35:13] we need instances with additional lvm volumes, yeah [17:35:53] the profile should support it already. we'll just need to request a flavor from wmcs folks [17:36:21] and more aggressive cache gc perhaps [17:37:27] brennen: add ^ to the list :) [17:39:23] 10Release-Engineering-Team (Doing), 10GitLab, 10User-brennen: runner-1002 is out of space - https://phabricator.wikimedia.org/T291221 (10brennen) Based on the docs under [[https://docs.gitlab.com/runner/executors/docker.html#clearing-docker-cache | clearing Docker cache ]], I ran: `lines=10 brennen@runner-1... [17:40:01] shoulda checked scrollback in here a bit sooner. :) [17:40:15] anyway, as commented above, there's a https://gitlab.com/gitlab-org/gitlab-runner/blob/main/packaging/root/usr/share/gitlab-runner/clear-docker-cache [17:40:28] ah, ok. we should add that to the profile [17:42:13] and whoops. the lvm volumes are deprecated https://wikitech.wikimedia.org/wiki/Help:Adding_Disk_Space_to_Cloud_VPS_instances#With_LVM_(deprecated_as_of_February,_2021) [17:44:15] but looks like we can refactor the profile to use `cinderutils::ensure` e.g. https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/refs/heads/production/modules/profile/manifests/wmcs/kubeadm/worker.pp#7 [17:44:15] yeah, seems like we may need to request additional storage quota for using cinder? [17:44:22] oh nice [17:45:49] sorry, i would put all that in a task but i'm doing train :/ [17:46:04] dduvall: no worries i'll summarize [17:50:56] 10Release-Engineering-Team (Doing), 10Release, 10Train Deployments: 1.38.0-wmf.1 deployment blockers - https://phabricator.wikimedia.org/T281165 (10dduvall) The release-notes diff between the errant 1.37.0-wmf.24 branch cut and the later 1.38.0-wmf.1 branch cut can be seen here. https://www.mediawiki.org/w/... [17:51:48] 10Release-Engineering-Team (Doing), 10GitLab, 10User-brennen: runner-1002 is out of space - https://phabricator.wikimedia.org/T291221 (10brennen) Notes from IRC discussion in `#wikimedia-releng`: - a `docker system prune -af` would probably also work - we should add a daily timer to the profile to run [[htt... [18:45:04] (03PS5) 10Jeena Huneidi: Build mediawiki image in train-dev [tools/train-dev] - 10https://gerrit.wikimedia.org/r/716060 (https://phabricator.wikimedia.org/T287993) [18:46:30] (03CR) 10Jeena Huneidi: Build mediawiki image in train-dev (037 comments) [tools/train-dev] - 10https://gerrit.wikimedia.org/r/716060 (https://phabricator.wikimedia.org/T287993) (owner: 10Jeena Huneidi) [18:47:04] (03CR) 10Jeena Huneidi: Build mediawiki image in train-dev (031 comment) [tools/train-dev] - 10https://gerrit.wikimedia.org/r/716060 (https://phabricator.wikimedia.org/T287993) (owner: 10Jeena Huneidi) [18:48:16] (03PS6) 10Jeena Huneidi: Build mediawiki image in train-dev [tools/train-dev] - 10https://gerrit.wikimedia.org/r/716060 (https://phabricator.wikimedia.org/T287993) [18:50:07] dduvall: I somehow thought Mukunda was doing the train this week bah ;D [18:50:17] I thought so too [18:50:31] dduvall: have you sorted out the branch version? [18:51:03] yep. deployed to testwikis and waiting for the window [18:51:31] with same sha1 from last night or from whatever was the tip of branches like an hour ago? [18:52:01] no, i went ahead with the cut from HEAD [18:52:09] the more recent one [18:52:18] we should mention that to wikitech-l etc [18:52:21] https://phabricator.wikimedia.org/T281165#7369777 [18:52:41] cause "maybe" someone got a change merged today assuming it would not be included in the train [18:52:56] though most probably, I am not sure people realize when we cut the branch for prod so.. [18:53:23] yeah, i'm not sure [18:53:45] hashar: could you email wikitech-l while i deploy? [18:54:08] group0 should be safe enough, but it would be good for folks to know before tomorrow [18:54:26] you can direct them to that phab comment or release-notes diff [18:57:05] I am sending the email ) [18:57:09] thx for the diff! [18:57:38] awesome. thanks, hashar <3 [18:58:02] also, thanks for cleaning up old version last week! [18:58:09] *versions [19:00:21] done and entering meeting ;) [19:00:29] oh yeah old version [19:00:44] we might still not clear l10n files or some cache though [19:01:02] iirc I just ran the instructed `scap clean` commands [19:03:34] dduvall: as for alst week, not much happened. The few blockers gotquickly fixed. Some errors still need to be addressed but are being worked on and have been filtered out of the mediawiki-new-errors board ;) [19:04:06] right on. thanks for the update [19:04:45] and the list of risky patch is great to have [19:15:07] 10Release-Engineering-Team (Doing), 10Release, 10Train Deployments: 1.38.0-wmf.1 deployment blockers - https://phabricator.wikimedia.org/T281165 (10dduvall) [19:17:28] 10Release-Engineering-Team (Yak Shaving 🐃🪒), 10GitLab, 10dev-images, 10Patch-For-Review, 10User-brennen: Migrate releng/dev-images to GitLab - https://phabricator.wikimedia.org/T290259 (10brennen) 05Open→03Resolved p:05Triage→03Medium a:03brennen [19:20:50] 10Release-Engineering-Team (Doing), 10Release, 10Train Deployments: 1.38.0-wmf.1 deployment blockers - https://phabricator.wikimedia.org/T281165 (10dduvall) [19:20:57] 10Release-Engineering-Team (Doing), 10Release, 10Train Deployments: 1.38.0-wmf.1 deployment blockers - https://phabricator.wikimedia.org/T281165 (10dduvall) [19:29:36] 10Release-Engineering-Team (Next), 10GitLab (Project Migration), 10User-brennen, 10Voice & Tone: Rename mainline Git branch from "master" to "main" on all WMF-hosted repositories during GitLab migration - https://phabricator.wikimedia.org/T281593 (10brennen) [19:29:49] 10Release-Engineering-Team (Yak Shaving 🐃🪒), 10GitLab (Project Migration), 10User-brennen: Migrate mediawiki/tools/release/ to GitLab - https://phabricator.wikimedia.org/T290260 (10brennen) [19:30:43] 10Release-Engineering-Team (Doing), 10GitLab (Project Migration), 10User-brennen: Early adoption signup for WMF GitLab - https://phabricator.wikimedia.org/T282842 (10brennen) [19:38:29] 10Release-Engineering-Team (Radar), 10Infrastructure-Foundations, 10GitLab (Infrastructure), 10Patch-For-Review, and 3 others: Puppetise gitlab-ansible playbook - https://phabricator.wikimedia.org/T283076 (10brennen) [19:42:44] 10Release-Engineering-Team (Doing), 10GitLab (Auth & Access), 10User-brennen: Increase GitLab session lifetime to something reasonable - https://phabricator.wikimedia.org/T288757 (10brennen) [19:42:46] 10Release-Engineering-Team (Doing), 10SRE, 10GitLab (Auth & Access), 10User-brennen: Define auth strategy for GitLab - https://phabricator.wikimedia.org/T274461 (10brennen) [19:42:52] 10Release-Engineering-Team (Doing), 10GitLab (Auth & Access), 10Patch-For-Review, 10Privacy, 10User-brennen: GitLab uses 'real name' as username (rather than 'shell name' or an user-specified name) - https://phabricator.wikimedia.org/T288392 (10brennen) [19:42:52] 10Release-Engineering-Team (Doing), 10GitLab (Auth & Access), 10Privacy, 10User-brennen: Investigate renaming existing users on gitlab - https://phabricator.wikimedia.org/T289510 (10brennen) [19:43:09] 10Release-Engineering-Team (Next), 10gitlab-settings, 10GitLab (Auth & Access), 10User-brennen: gitlab-settings: Automate people/* group policies - https://phabricator.wikimedia.org/T288697 (10brennen) [19:43:15] 10Release-Engineering-Team (Doing), 10Infrastructure-Foundations, 10CAS-SSO, 10GitLab (Auth & Access), and 2 others: Open gitlab.wikimedia.org to all users with Wikimedia developer accounts - https://phabricator.wikimedia.org/T288162 (10brennen) [19:46:38] 10Release-Engineering-Team (Doing), 10GitLab (CI & Job Runners), 10User-brennen: runner-1002 is out of space - https://phabricator.wikimedia.org/T291221 (10brennen) [19:46:53] 10Release-Engineering-Team (Seen), 10GitLab (CI & Job Runners), 10User-brennen: Document long-term requirements for GitLab job runners - https://phabricator.wikimedia.org/T286958 (10brennen) [19:47:14] 10Continuous-Integration-Infrastructure, 10Release-Engineering-Team (Doing), 10Release Pipeline, 10GitLab (CI & Job Runners), 10User-brennen: Figure out the future of (or replacements for) PipelineLib in a GitLab world - https://phabricator.wikimedia.org/T287211 (10brennen) [19:47:47] 10Release-Engineering-Team (Yak Shaving 🐃🪒), 10GitLab (Infrastructure), 10User-brennen: Enable incoming mail handling for GitLab - https://phabricator.wikimedia.org/T284961 (10brennen) [19:48:45] 10Release-Engineering-Team (Seen), 10GitLab-Test, 10GitLab (Project Migration), 10User-brennen: Proof of concept for cross-repo dependencies - https://phabricator.wikimedia.org/T262618 (10brennen) [19:52:48] 10Phabricator, 10Release-Engineering-Team (Doing), 10GitLab-Test, 10GitLab (Integrations), 10User-brennen: Experiment with GitLab-Phabricator integration - https://phabricator.wikimedia.org/T265617 (10brennen) [19:52:53] 10Release-Engineering-Team (Doing), 10GitLab-Test, 10GitLab (Integrations), 10User-brennen: Experiment with package publishing workflows on GitLab - https://phabricator.wikimedia.org/T264131 (10brennen) [19:53:03] 10Release-Engineering-Team (Next), 10wikimedia.biterg.io, 10GitLab (Integrations): Bitergia gitlab read access for metrics - https://phabricator.wikimedia.org/T290247 (10brennen) [19:55:33] 10Release-Engineering-Team (Doing), 10GitLab (Administration, Settings & Policy), 10User-brennen: Investigate whether issues, operations, wikis, etc. can be disabled globally on GitLab - https://phabricator.wikimedia.org/T264231 (10brennen) [19:55:56] 10Release-Engineering-Team (Doing), 10Documentation, 10GitLab (Misc), 10User-brennen: Document GitLab Development Kit setup on-wiki - https://phabricator.wikimedia.org/T268269 (10brennen) [19:55:58] 10Release-Engineering-Team (Next), 10GitLab (Administration, Settings & Policy), 10User-brennen: Establish a routine GitLab deployment / update window - https://phabricator.wikimedia.org/T287117 (10brennen) [19:56:17] 10Release-Engineering-Team (Yak Shaving 🐃🪒), 10GitLab (Administration, Settings & Policy), 10User-brennen: GitLab project templates include issues - figure out if these can be customized or removed - https://phabricator.wikimedia.org/T290612 (10brennen) [19:56:19] 10Release-Engineering-Team (Radar), 10GitLab-Test, 10GitLab (Administration, Settings & Policy), 10Upstream, 10User-brennen: Look into whether GitLab time tracking can be disabled - https://phabricator.wikimedia.org/T264230 (10brennen) [19:57:09] 10Release-Engineering-Team (Next), 10ContentSecurityPolicy, 10GitLab (Administration, Settings & Policy), 10User-brennen: Define a Content Security Policy for GitLab - https://phabricator.wikimedia.org/T285363 (10brennen) [19:57:16] 10Release-Engineering-Team (Seen), 10GitLab (Project Migration), 10User-brennen: Figure out submodule updating in GitLab - https://phabricator.wikimedia.org/T268283 (10brennen) [19:57:26] 10Release-Engineering-Team (Yak Shaving 🐃🪒), 10Code-Health, 10Developer Productivity, 10GitLab (Integrations), 10User-brennen: Investigate whether we can/should integrate Git/Reviewers with GitLab - https://phabricator.wikimedia.org/T289712 (10brennen) [20:14:41] 10Release-Engineering-Team (Doing), 10GitLab-Test, 10GitLab (Integrations), 10User-brennen: Experiment with package publishing workflows on GitLab - https://phabricator.wikimedia.org/T264131 (10Addshore) I havn't played around with composer packaged on gitlab, but I have played around with generic packages... [20:19:03] (03PS7) 10Jeena Huneidi: Build mediawiki image in train-dev [tools/train-dev] - 10https://gerrit.wikimedia.org/r/716060 (https://phabricator.wikimedia.org/T287993) [20:29:22] 10Release-Engineering-Team (Seen), 10Page-Previews, 10patch-welcome: Popups should not use github.com for documentation generation - https://phabricator.wikimedia.org/T243263 (10LGoto) [20:42:31] 10Release-Engineering-Team (Doing), 10Release, 10Train Deployments: 1.38.0-wmf.1 deployment blockers - https://phabricator.wikimedia.org/T281165 (10DannyS712) [20:50:27] 10MediaWiki-Releasing, 10MW-1.38-release, 10MobileFrontend (Tracking): Bundle MobileFrontend extension with MediaWiki - https://phabricator.wikimedia.org/T191734 (10Jdlrobson) [20:50:32] 10MediaWiki-Releasing, 10MW-1.38-release, 10MinervaNeue (Tracking): Bundle MinervaNeue skin with MediaWiki - https://phabricator.wikimedia.org/T191743 (10Jdlrobson) [20:55:34] 10Phabricator: Evaluate adding "In progress" status to Phabricator. - https://phabricator.wikimedia.org/T288956 (10Zabe) Btw tasks set to "in progress" are not visible on the main page ate 'new tasks', like tasks set to 'stalled'. [21:03:02] 10Release-Engineering-Team (Seen), 10MW-on-K8s, 10Platform Engineering Roadmap, 10User-Daniel: Convert static mediawiki configuration to form more suitable for containers - https://phabricator.wikimedia.org/T263166 (10Legoktm) >>! In T263166#7300889, @daniel wrote: > Based on my limited understanding of Ku... [21:13:20] (03PS1) 10Ahmon Dancy: Make initialize-mediawiki-staging idempotent [tools/train-dev] - 10https://gerrit.wikimedia.org/r/722681 [21:39:05] (03CR) 10Ahmon Dancy: Build mediawiki image in train-dev (039 comments) [tools/train-dev] - 10https://gerrit.wikimedia.org/r/716060 (https://phabricator.wikimedia.org/T287993) (owner: 10Jeena Huneidi) [21:57:47] (03PS1) 10Ahmon Dancy: make-container-image: Allow name of workdir volume to be specified [tools/release] - 10https://gerrit.wikimedia.org/r/722690 [21:58:39] (03CR) 10Ahmon Dancy: [C: 03+2] make-container-image: Allow name of workdir volume to be specified [tools/release] - 10https://gerrit.wikimedia.org/r/722690 (owner: 10Ahmon Dancy) [22:00:11] (03Merged) 10jenkins-bot: make-container-image: Allow name of workdir volume to be specified [tools/release] - 10https://gerrit.wikimedia.org/r/722690 (owner: 10Ahmon Dancy) [22:44:21] (03CR) 10Jeena Huneidi: [C: 03+2] "LGTM" [tools/train-dev] - 10https://gerrit.wikimedia.org/r/722681 (owner: 10Ahmon Dancy) [22:52:09] (03CR) 10Ahmon Dancy: [V: 03+2] Make initialize-mediawiki-staging idempotent [tools/train-dev] - 10https://gerrit.wikimedia.org/r/722681 (owner: 10Ahmon Dancy) [22:56:16] (03PS8) 10Jeena Huneidi: Build mediawiki image in train-dev [tools/train-dev] - 10https://gerrit.wikimedia.org/r/716060 (https://phabricator.wikimedia.org/T287993) [22:56:34] (03CR) 10Jeena Huneidi: Build mediawiki image in train-dev (038 comments) [tools/train-dev] - 10https://gerrit.wikimedia.org/r/716060 (https://phabricator.wikimedia.org/T287993) (owner: 10Jeena Huneidi) [23:01:52] (03CR) 10Ahmon Dancy: "Just a couple of minor nits, otherwise LGTM. I'm almost done with the image builder mods" [tools/train-dev] - 10https://gerrit.wikimedia.org/r/716060 (https://phabricator.wikimedia.org/T287993) (owner: 10Jeena Huneidi) [23:06:28] (03PS1) 10Ahmon Dancy: WIP: auto-stage mods for train-dev [tools/release] - 10https://gerrit.wikimedia.org/r/722696 [23:07:34] (03CR) 10jerkins-bot: [V: 04-1] WIP: auto-stage mods for train-dev [tools/release] - 10https://gerrit.wikimedia.org/r/722696 (owner: 10Ahmon Dancy) [23:11:42] (03PS2) 10Ahmon Dancy: auto-stage mods for train-dev [tools/release] - 10https://gerrit.wikimedia.org/r/722696 [23:15:24] (03CR) 10Ahmon Dancy: [C: 03+2] auto-stage mods for train-dev [tools/release] - 10https://gerrit.wikimedia.org/r/722696 (owner: 10Ahmon Dancy) [23:16:15] (03Merged) 10jenkins-bot: auto-stage mods for train-dev [tools/release] - 10https://gerrit.wikimedia.org/r/722696 (owner: 10Ahmon Dancy)