[09:43:10] forgot to remove the gerrit commit-msg hook after we moved the cirrus-streaming-updater project to gitlab [09:43:33] looking at git log seems like I'm not the only one :) [09:51:29] lunch [10:20:09] lunch 2 [11:38:07] lunch [13:35:40] o/ [13:58:59] hm.. this is scary curl https://en.wikipedia.org -> curl: (60) SSL: no alternative certificate subject name matches target host name 'en.wikipedia.org' on my system... [13:59:38] wonder what I broke with curl, lynx or my browser does work [14:29:08] inflatador, ryankemper: I'll skip our pairing session tomorrow. For once, I'll try to have a social life! [14:32:38] * inflatador wonders what having a social life is like [15:01:10] * ebernhardson somehow aligned okta sign-in with wednesday morning... [15:02:56] dcausse: pfischer inflatador meeting started [15:31:23] ryankemper, stevemunene: we're in https://meet.google.com/zia-croa-wru [16:09:32] wokrout, back in ~40 [17:13:11] sorry, been back [17:45:52] lunch, back in ~45 [18:05:43] quasi related to earlier, an interview with zuck about llama2. Talks about crowd-sourcing rlhf "wikipedia style" around 5m. https://www.youtube.com/watch?v=6PDk-_uhUt8 [18:37:33] Good news, i managed to merge a patch fixing the CI for mwcli, so will get onto merging things now and make a new release real soon [18:37:44] \o/ [18:38:54] so is cindy the browser test bot using mwcli somehow? [18:39:16] addshore: yes, it's using these scripts now: https://gitlab.wikimedia.org/repos/search-platform/cirrus-integration-test-runner/-/tree/main/ [18:39:47] it's a bit awkward in places, but seems to work [18:40:02] epic, thats one of the things I kind of designed it for, easy programmatic setup of a mw environment :D [18:40:19] Do let me know which bits are the most awkward, as I can probably improve them a bit :D [18:40:48] it does some weird things...i thought i should be able to setup multiple wikis in parallel (because we spend ~2 minutes just setting up the env), but when i try to i hit race conditions in how mwcli overwrites the files on disk [18:41:05] the stuff in ~/.config/mwcli [18:41:29] aah yeah, in terms of mediawiki installation, mediawiki requires LocalSettings.php to not exist when install.php is run, so mwcli has to move it out the way for each install [18:42:04] I think MW should make the non existence of LocalSettings.php optional really [18:42:07] otherwise, it mostly works. i don't think we do anything too crazy. [18:42:18] woo! [18:42:29] well, i look forward to being able to maintain it a little more now im back on dry land :D [18:43:00] when the CI is working its fairly easy to merge contributions in too, as the core usecases are all covered by the integration tests [18:43:09] and releasing is all entirely automated in CI too [18:43:30] excellent. I suppose the other awkward thing i did is create my own LocalSettings.d abstraction that manages per-wiki config files [18:43:32] but it's awkard :P [18:44:18] hehe, not sure if I should bake something LocalSettings.d like into it or not? maybe i should [18:44:40] but i guess you might also benefit from the idea of having an entire mwcli docker setup defined in a yaml file, so you could set it up with a single command? [18:45:13] I dunno, i think it is a common problem people are going to have, although i suppose i don't know how many systems actually have explicit cross-wiki integrations to test other than us [18:45:54] back [18:46:01] ebernhardson: I made https://phabricator.wikimedia.org/T342290 [18:46:30] hmm, integrating it all into a declarative yaml could be interesting. I wonder how we would test those though, imo the problem mwvagrant ran into was there were so many ways to run it that the combinatorial explosion of possible roles meant whatever you were running was almost certainly untested by people commiting changes to the vagrant repo [18:48:08] i suppose if there are a few base recipes tested by ci and you corral people into those recipes, maybe it would be reliable [18:59:40] My 9-yr-old sent me a link to Hugging Face yesterday and told me "Dad, I want to make an AI" [19:00:37] I think basically the YAML files would leave it up to teams and users to define their yaml etc themselves. All mwcli would ensure is that it could for example 1) set the env vars right 2) get the right code 3) install the right sites 4) run the rgiht services 5) Add the LocalSettings stuff that is defined and 6) have "hooks" for doing thing before and or after steps 7) be repetable [19:01:07] the main usecase I was thinking of was onboarding a new person into a team, rather than have them run a bunch of commands, they run 1 which points at the teams agreed yaml starting point, and tada [19:08:39] perhaps would be viable, it's certainly still slow to set everything up. I'm using the same cindy env as my local development, but i don't think anyone else is [19:29:07] * ebernhardson didn't realize mediasearch excludes pdf [19:34:46] quick break, back in ~15 [19:47:11] LOL, forgot to break. Let's wait till 3 then [19:49:47] sigh..realizing after walking through how mediasearch works it's not going to be as easy as wrapping some high-level actions :( [20:00:43] OK, break time for real! https://cdn.mobygames.com/screenshots/15745020-pac-land-turbografx-16-break-time.png [20:26:37] back [21:28:44] * ebernhardson always worries when docs say thing like 'Should return a promise' [21:28:56] like, where does that should come from. What else can be returned? :)