[22:25:27] the CI failure at https://gerrit.wikimedia.org/r/c/performance/excimer-ui-client/+/868219 is because the docker images lack excimer, should I just add it to the Dockerfile.template files? [22:32:57] composer needs running on PHP 7.4 though for it to pass there too (or don't commit the lock file) [22:37:18] yeah, I made a PHP 7.4 lock file for https://gerrit.wikimedia.org/r/c/performance/excimer-ui-server/+/868222 so I was going to do the same thing for the client [22:52:45] TimStarling: Installing should be fine unconditionally I think in the base. No harm afaik [22:53:18] Not sure it's available for php8+ yet though. It didn't work for me in Mw docker, as we don't have it in the wmf channels yet [22:53:36] it's in the ondrej PPA [22:53:51] We use sury afaik [22:53:56] I asked them to add it recently [22:54:02] So I guess that will work now [22:54:57] https://gerrit.wikimedia.org/r/c/integration/config/+/875443 [22:55:02] untested [22:56:20] https://www.mediawiki.org/wiki/Continuous_integration/Docker#Build_images_locally [22:56:52] I'd test it locally with `docker-pkg -c dockerfiles/config.yaml build --select '*/php*' dockerfiles/` or some such [22:57:05] I think this won't work on its own yet as it needs to be propagated to the composer images right? [22:57:38] "this may take several hours, and ± 40GB disk space" [22:57:39] https://www.mediawiki.org/wiki/Continuous_integration/Docker#Adjusting_an_image [22:57:42] that command will do it automatically [22:58:00] TimStarling: yeah, I don't recommend rebuilding all images and don't recomend doing it locally for base images [22:58:19] instead you can download the few images you need and then only rebuild your modified change on top so the last layer only [22:59:33] you can use docker pull for the php* and composer* images, so that you have the latest version of those and their parents implicitly. And then a rebuild will only build the new version's layer on top of those. [23:00:04] docker stores stuff by url-like indentifiers, so if you don't pull first it will rebuild it all locally from source, but if you pull them first, then it won't. [23:00:21] anyway, you prolly know that already but this is my own little simplified way of thinking about it [23:07:54] thinking about what a full-on local CI infrastructure would look like [23:20:15] setting up a top-level container which will have docker in it [23:21:12] https://doc.wikimedia.org/quibble/ is a partial local CI thing at least for MediaWiki bits [23:31:27] yeah, I last installed it locally in 2019, I used virtualbox back then [23:32:34] today, trying to do it in systemd-nspawn [23:33:55] not quibble today, just docker, to test my dockerfile patches [23:47:10] TimStarling: in terms of compromised dialect, do you mean less-pretty-but-standard-SQL that both mysql and sqlite support? I get most of the way there (INTEGER is fine, VARCHAR(200) is just TEXT but sqlite groks that as-is). TIMESTAMP I guess we can format in PHP. Not sure about LONGBLOB though. BLOB is presumably too small in MySQL and LONGBLOB isn't standard. [23:47:34] hm.. despite no match for `ack -i longblob` in sqlite3 source, it actually groks it fine? [23:47:45] I guess the syntax it cares about is lenient/ignores it? [23:47:52] even FOOBAR itll grok [23:49:36] do you have a preferred date format? MW VARCHAR 14? ISO VARCHAR 20? [23:50:13] sqlite has a lot of hacks to make it mostly understand mysql syntax, it's designed for this [23:50:30] ack, I did try it as-is, but ran into numerous syntax errors. [23:50:37] I over compensated I see. [23:53:55] looks like it doesn't have datesub() so that will have to be done in a different way [23:54:28] or you could just do apt-get install mariadb-server [23:54:41] save us some trouble