[05:20:31] 10Gerrit, 10Release-Engineering-Team (Radar), 10Upstream: Gerrit names misalignment in 3.3.5 - https://phabricator.wikimedia.org/T288035 (10Paladox) Change is merged. Backported to 3.3 here https://gerrit-review.googlesource.com/c/gerrit/+/314022 [05:55:23] 10Gerrit, 10Release-Engineering-Team (Radar), 10Upstream: Gerrit names misalignment in 3.3.5 - https://phabricator.wikimedia.org/T288035 (10Paladox) >>! In T288035#7265744, @Paladox wrote: > Change is merged. Backported to 3.3 here https://gerrit-review.googlesource.com/c/gerrit/+/314022 Backport merged now! [06:40:04] 10Phabricator, 10DBA: Failover m3 (phabricator) master (db1132) to a different host to upgrade its kernel - https://phabricator.wikimedia.org/T288197 (10Marostegui) I will reimage db1107 on Monday as it was switched over yesterday, let's give the new master till Monday just in case. [06:43:28] 10Phabricator, 10DBA: Failover m3 (phabricator) master (db1132) to a different host to upgrade its kernel - https://phabricator.wikimedia.org/T288197 (10Marostegui) [07:17:36] 10Release-Engineering-Team, 10GitLab: WARNING: In GitLab 14.0 we will begin removing all configuration backups older than yourgitlab_rails['backup_keep_time'] setting (currently set to: 259200) - https://phabricator.wikimedia.org/T288324 (10jcrespo) [10:24:42] 10Release-Engineering-Team, 10GitLab: WARNING: In GitLab 14.0 we will begin removing all configuration backups older than yourgitlab_rails['backup_keep_time'] setting (currently set to: 259200) - https://phabricator.wikimedia.org/T288324 (10Jelto) a:03Jelto [14:48:11] Hi there. I have some extension deployment questions. Am I in the right place to pose them? [14:48:35] possibly [14:48:41] depends what the actual question is though... :) [14:49:05] mmk, I'll just jump in then. [14:50:40] We've gone through the various review steps and deployed our extension to beta cluster a while back [14:51:41] Which one [14:51:41] The extension is `TheWikipediaLibrary`, and it basically exists to send a notification to users across as many projects as possible about their eligibility for using the library [14:51:43] https://phabricator.wikimedia.org/T288070 [14:52:40] Eligibility is based on global edits, and we want to start out by deploying with a high required edit count and then draw it down over time [14:53:26] I'm not really clear on how we would go about doing such a deployment with followup configuration changes that are coordinated across multiple projects [14:54:10] Could you not use a $wgBlah variable and then just change it via B&C window when needed [14:54:32] Yes, that's the idea, and exactly where my questions come in [14:54:45] What questions [14:55:01] Is it possible to deploy those configuration changes across multiple projects simultaneously? [14:55:06] or feasible? [14:55:14] What do you mean? [14:55:19] All wikis run on the same code/config... [14:55:27] The same config file runs everywhere [14:55:29] So when you deploy it, it is everywhere (in a matter of seconds) [14:56:01] Okay, so the configuration isn't local per-project? [14:56:27] Not unless you're using some sort of on wiki configuration JSON type page [14:56:37] It can be set per-project if needed too, but it all comes from a central source [14:56:53] Everything is in https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings-labs.php https://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php https://noc.wikimedia.org/conf/highlight.php?file=CommonSettings-labs.php [14:57:05] Yeah, you can apply config based on different groupings (or specifically and individually) [14:58:08] Sorry, by "All wikis run on the same code/config..." I didn't mean "it must be the same config on every individual wiki" [15:01:34] So it sounds like the default configuration deployment is global, and you have to go out of your way to customize it for a given project? So if we set our configuration in CommonSettings, we can expect `en`, `de`, `fr` etc to all get the same values? [15:01:34] it doesn’t sound like you actually need this threshold to be different per wiki, if I understand correctly? [15:01:44] correct, we want it to be the same [15:01:57] yeah, I think you could put `$wgWhateverThreshold = 50000;` in CommonSettings.php [15:02:11] and then later change it to 10000 and sync that, and it’ll apply to all wikis at once [15:02:18] ^ [15:02:34] If you need a different value per wiki, that's doable, and needs a little bit more work, but it's not much work [15:02:43] +1 [15:02:50] and is perfectly acceptable to do [15:02:56] Awesome. Sometimes when things seem very simple, it makes me worry that I'm misunderstanding something very basic. [15:03:06] Thanks all! [15:03:07] I mean, if you open the config file... [15:03:11] you see thousands of lines of PHP [15:03:14] it's pretty daunting :) [15:03:41] yeah I no longer try to edit IS.php with emacs, it’s too big ^^ [15:04:20] That's why I stopped doing config changes [15:04:42] Couldn't find anything that would cope with the size [15:04:59] nano seems to not have an issue [15:05:07] try getting github to show you the blame for IS.php to see the true power of that huge and complex config file [15:05:13] heh [15:05:14] vim also works pretty well for me [15:05:22] github fails for much smaller pages too :P [15:06:41] Github blame is dodgy [15:31:17] (03PS1) 10Ahmon Dancy: Use docker-registry.wikimedia.org/php7.2-fpm-multiversion-base [tools/release] - 10https://gerrit.wikimedia.org/r/710579 [16:03:23] (03CR) 10Ahmon Dancy: [C: 03+2] Use docker-registry.wikimedia.org/php7.2-fpm-multiversion-base [tools/release] - 10https://gerrit.wikimedia.org/r/710579 (owner: 10Ahmon Dancy) [16:04:29] (03Merged) 10jenkins-bot: Use docker-registry.wikimedia.org/php7.2-fpm-multiversion-base [tools/release] - 10https://gerrit.wikimedia.org/r/710579 (owner: 10Ahmon Dancy) [16:31:29] (03PS5) 10Ahmon Dancy: Make image build process work with Docker Desktop (Mac OS) [tools/release] - 10https://gerrit.wikimedia.org/r/709867 [16:39:38] (03PS6) 10Ahmon Dancy: Make image build process work with Docker Desktop (Mac OS) [tools/release] - 10https://gerrit.wikimedia.org/r/709867 [16:40:01] (03PS7) 10Ahmon Dancy: Make image build process work with Docker Desktop (Mac OS) [tools/release] - 10https://gerrit.wikimedia.org/r/709867 [16:43:29] (03CR) 10Ahmon Dancy: [C: 03+2] "Tested on my macbook and other Linux systems." [tools/release] - 10https://gerrit.wikimedia.org/r/709867 (owner: 10Ahmon Dancy) [16:44:22] (03Merged) 10jenkins-bot: Make image build process work with Docker Desktop (Mac OS) [tools/release] - 10https://gerrit.wikimedia.org/r/709867 (owner: 10Ahmon Dancy) [18:29:04] brennen: what will the repo hierarchy for wmcs tools look like on gitlab? for example, do we need to port toolsadmin.wikimedia.org code that creates phab repos to gitlab or will gitlab allow self-service repo creation without external tools? [18:41:28] majavah: good questions for WMCS folks, i think. [18:44:00] gitlab does allow for self-service repo creation, both under an individual user's namespace and in groups where people have the right permissions, but i could see it making sense to adapt something like striker to create tool repos under a specific limited group. [18:49:13] it would be really nice if toolsadmin/striker could sync ACLs so that if you're added to the tool, you also get Git repo access [18:49:42] right now when it creates a repo on Phab it adds all the current tool members as owners, but any later added people have to be manually added [18:59:28] that feels possible, i think. [19:12:10] * addshore goes back to playing around with gitlab and CI [19:41:44] 10Release-Engineering-Team (Doing), 10Infrastructure-Foundations, 10CAS-SSO, 10GitLab (Initialization), and 2 others: Open gitlab.wikimedia.org to all users with Wikimedia developer accounts - https://phabricator.wikimedia.org/T288162 (10brennen) Turns out I need to get better at calendar-stalking in the g... [20:24:46] jeena: party time? :P [20:25:13] lol [20:26:17] what do we think, is it possible for us to mirror some dockerhub images on a wikimedia controlled registry somewhere? [20:31:21] why do we need to mirror them? [20:32:09] Because of the rate limits on pulls :/ [20:33:13] oh [20:33:51] So if 1 pull request or change on mwcli, ends up pulling 4 images from docker hub, in 4 different CI runs adds up [20:33:52] which images? (My hunch is it won't be advisable to mirror them but maybe we can build our own ones) [20:33:59] the limit is 100 pulls per 6 hours in total [20:34:07] *checks* [20:35:21] adminer, defreitas/dns-proxy-server, jwilder/nginx-proxy, graphiteapp/graphite-statsd, maraidb, mysql, postgres, phpmyadmin, redis [20:36:55] wheeee [20:37:21] certainly not the shortest of lists [20:37:25] haha [20:37:29] I'll make a task [20:37:39] hehe [20:38:17] i should figure out how to make devrel images [20:43:44] you mean like the ones in https://gerrit.wikimedia.org/g/releng/dev-images? [20:43:47] ya [20:43:50] im reading the readme now [20:43:54] ah [20:44:23] https://doc.wikimedia.org/docker-pkg/ doesnt say how to downlaod it D: [20:44:55] hmm I can never remember but I thought that I downloaded the repo and ran some build script [20:45:47] hah, its in the readme for dev-images, iu just hadnt got there yet! [20:45:57] :) [20:46:16] https://www.mediawiki.org/wiki/Continuous_integration/Docker#Installing_docker-pkg [20:46:16] :P [20:47:01] I now remember i tried to make a docker image for docker-pkg once [20:48:36] documentation labyrinth is so fun [20:54:28] why does it have to pull the images every time? does the github ci make a new local docker registry for each CI run? [20:57:04] addshore: https://phabricator.wikimedia.org/T288377 [21:00:57] thats a good question [21:01:26] the error was `Unable to find image 'hello-world:latest' locally` so i guess yes it gets pulled every time [21:01:42] as each CI run, runs within its own half fenced off docker thing [21:01:57] so even if the CI host has the image, the thing running docker for the CI does not [21:02:08] hmm [21:03:37] * addshore reads https://docs.gitlab.com/ee/user/packages/container_registry/ [21:03:41] `If you pull container images from Docker Hub, you can also use the GitLab Dependency Proxy to avoid running into rate limits and speed up your pipelines.` [21:04:20] do we have that? :P [21:05:52] I also saw on gitlab that we can change the pull policy [21:06:10] but I was mostly looking for github stuff [21:06:23] but maybe changing focus to gitlab is good [21:06:50] yeah, id love to get away from this split dev stuff between github and gerrit [21:07:02] the CI is close and this docker image question is probably the only open thing [21:07:10] then we could just move it TM [21:08:32] cool [21:09:17] heh, even the CI runner itself uses and pulls a docker image `Pulling docker image docker:19.03.12-dind` [21:15:12] lol [21:19:01] it looks like a mirror could be quite trivial actually https://about.gitlab.com/blog/2020/10/30/mitigating-the-impact-of-docker-hub-pull-requests-limits/ [21:20:22] interesting [21:20:32] also there is a google mirror that seemignly doesnt need auth :P [21:20:42] so, how can we make a mwcli repo in gitlab? [21:20:49] or if I make one on my user can we move it after? [21:22:06] let me take a look [21:27:53] I can't seem to create a group so we'd have to put it in a different namespace than it is now [21:28:48] or maybe someone else can make the group [21:37:02] addshore: https://gitlab.wikimedia.org/releng/cli disclaimer that things on gitlab might not be completely functional right now [21:37:09] wooooo [21:37:25] i always enjoy testing things where folks give that sort of disclaimer ;) [21:37:30] LOL [21:38:04] * thcipriani suddenly nervous [21:38:15] basically, I know nothing about what we can and can't do on gitlab but I do have this roadmap link: https://www.mediawiki.org/wiki/GitLab/Roadmap#%F0%9F%9A%A7_Explorers [21:40:50] ooo, the code is already there too [21:40:51] <3 [21:41:05] * addshore requests access to the repo [21:43:59] I have to give access? I thought it was public [21:46:05] I think i need some sort of extra access to configure CI etc [21:46:29] collaboration isn't really setup yet [21:46:43] like: in the releng namespace, there's just releng [21:46:45] I found the access granting spot. It didn't notify me though, just had to look for it [21:47:36] seemingly "Developer" is not enough access [21:47:41] LOL [21:47:58] I think I might need "Maintainer" to poke CI things [21:48:01] I changed it [21:48:03] ty! [21:48:17] * addshore jabs his fingers in things [21:49:01] thank you too! [21:58:05] well https://gitlab.wikimedia.org/releng/cli/-/jobs/183 [21:58:08] so far so good [21:58:34] I'll slowly try and replicat the CI i made on github on a branch, and if it works we can merge it in [22:04:06] addshore: Fancy. [22:07:31] nice! [22:09:08] its feels very similar to github actions, which is nice [22:11:55] jeena: I have sad news about excluding the charts sub directory from the toolhub chart. local-charts will pull in the chart but does not also pull in the dependencies. So I end up with a chart that doesn't install elasticsearch even when the values.yaml has the proper trigger to do so. Interestingly no errors either. [22:13:01] I'm not finding any really clear upstream doc about how you are supposed to do this. If the vendored sub chart is the "correct" thing or if I'm ust not doing the right dance in local-charts to handle charts with un-vendored deps. [22:13:09] bd808: I [22:13:29] 'll take another look, but given our current deployment process I think it needs to be included anyway [22:15:44] If I had to pick the smallest releng docker image that has git in it, what would it be? [22:16:13] wait, what is `docker-registry.wikimedia.org/releng/mediawiki-tarball` ? [22:16:31] addshore: A failed project from a while ago, I think. [22:17:28] hmm [22:17:40] actually, it just needs curl and something to untar with [22:17:43] i'm perusing the list of dockerfiles in integration/config [22:17:48] wait, bah, it needs composer too [22:18:44] then one of the composer-php ones I guess [22:19:05] Yeah, composer-php80-test is light and useful. [22:20:37] nom nom nom [22:21:34] * James_F shills his own images shamelessly. [22:24:34] Do we have a task for connecting wikibugs to GitLab? [22:26:48] (Filed as T288381.) [22:26:49] T288381: Connect WikiBugs IRC bot to Wikimedia GitLab - https://phabricator.wikimedia.org/T288381 [22:35:05] run to know the jobs in gitlab have a gloibal incrementing ID [22:35:12] I wonder how long it'll take to get to 1000000 [22:36:29] hahaha [22:39:41] Can someone either (a) give me magic rights to do it myself, or (b) import https://github.com/wikimedia/grunt-tyops into our GitLab as a non-personal repo? Maybe we should have a CI tools namespace for this and others? [22:40:10] *rages against the machine* I cant find any docker images with wget in [22:40:23] curl is your only hoooope [22:40:43] I can't make groups unfortunately. thcipriani mentioned that no one has really decided whether to stick with the same namespaces we have in gerrit or not [22:40:48] we need a dev-toolkit image or something :D [22:41:22] hmm maybe [22:41:29] addshore: Yeah, we chose curl over wget at some point. [22:41:45] oh yes, there is a /curl image?!!! [22:41:48] I know how to use curl better than wget anyway :P [22:41:54] yeah [22:42:00] curl >> wget. No, wait, not like that. ;-) [22:42:01] and I think curl is in the composer image [22:42:08] It is, yes. [22:42:27] hmmm `/usr/bin/curl: /usr/bin/curl: cannot execute binary file` [22:43:13] Yeah, I think we will need a generic image, where I can do things like wget or curl, and tar etc :P [22:43:27] releng/addshore-wanted-it-so-tough [22:43:37] 😂 [22:43:56] ;) [22:45:24] curl isnt in the composer ones D: [22:46:18] it is in composer-72 [22:46:35] and 73 [22:46:52] but not 74 or 80 [22:47:32] :D [22:48:46] Oh meh, yeah. [22:48:58] Vague memories of us factoring it out intentionally to slim down the top-level. [22:49:05] Years ago. [22:52:10] hmmm, https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/vendor/+archive/refs/heads/vendor.tar.gz give me a bad file D: [22:53:43] same from github though... meh [23:15:02] (03PS2) 10Jforrester: dockerfiles: [quibble-buster-php73-coverage] Add scripts for cover-skins [integration/config] - 10https://gerrit.wikimedia.org/r/709744 (https://phabricator.wikimedia.org/T287918) (owner: 10Reedy) [23:23:58] (03PS3) 10Jforrester: dockerfiles: [quibble-buster-php73-coverage] Add scripts for cover-skins [integration/config] - 10https://gerrit.wikimedia.org/r/709744 (https://phabricator.wikimedia.org/T287918) (owner: 10Reedy) [23:26:36] look at our fancy gitlab, reading jupyter notebooks: https://gitlab.wikimedia.org/thcipriani/train-stats/-/blob/main/README.ipynb [23:26:39] living in the future [23:27:03] niceee [23:27:27] we have had 12 blockers in a single train? D: [23:29:32] https://phabricator.wikimedia.org/T220745 [23:30:07] we have some fun weeks :) [23:31:23] actually, not sure what's up with that graph, we've had bigger weeks :) [23:32:44] https://gitlab.wikimedia.org/-/snippets/1 [23:33:25] maybe there should have been a less depressing snippet #1, but here we are [23:35:00] (03PS2) 10Jforrester: jjb: Add jobs for generating MediaWiki skin PHP code coverage reports [integration/config] - 10https://gerrit.wikimedia.org/r/709745 (https://phabricator.wikimedia.org/T287918) (owner: 10Reedy) [23:35:02] (03PS8) 10Jforrester: Zuul: Provide a skin-coverage template [integration/config] - 10https://gerrit.wikimedia.org/r/709575 (https://phabricator.wikimedia.org/T287918) (owner: 10Reedy) [23:35:04] (03PS1) 10Jforrester: jjb: Bump jobs using quibble-buster-php73-coverage from 1.0.1 to 1.1.0 [integration/config] - 10https://gerrit.wikimedia.org/r/710625 [23:37:25] (03PS4) 10Jforrester: dockerfiles: [quibble-buster-php73-coverage] Add scripts for cover-skins [integration/config] - 10https://gerrit.wikimedia.org/r/709744 (https://phabricator.wikimedia.org/T287918) (owner: 10Reedy) [23:37:27] (03PS2) 10Jforrester: jjb: Bump jobs using quibble-buster-php73-coverage from 1.0.1 to 1.1.0 [integration/config] - 10https://gerrit.wikimedia.org/r/710625 [23:37:29] (03PS3) 10Jforrester: jjb: Add jobs for generating MediaWiki skin PHP code coverage reports [integration/config] - 10https://gerrit.wikimedia.org/r/709745 (https://phabricator.wikimedia.org/T287918) (owner: 10Reedy) [23:37:31] (03PS9) 10Jforrester: Zuul: Provide a skin-coverage template [integration/config] - 10https://gerrit.wikimedia.org/r/709575 (https://phabricator.wikimedia.org/T287918) (owner: 10Reedy) [23:37:33] (03PS1) 10Jforrester: Zuul: [mediawiki/skins/Mirage] Not a production skin; move to right section [integration/config] - 10https://gerrit.wikimedia.org/r/710626 [23:37:35] (03PS1) 10Jforrester: Zuul: Add skin-coverage jobs to all Wikimedia production skins [integration/config] - 10https://gerrit.wikimedia.org/r/710627 (https://phabricator.wikimedia.org/T287918) [23:43:52] (03CR) 10Jforrester: [C: 03+2] Zuul: [mediawiki/skins/Mirage] Not a production skin; move to right section [integration/config] - 10https://gerrit.wikimedia.org/r/710626 (owner: 10Jforrester) [23:44:55] (03Merged) 10jenkins-bot: Zuul: [mediawiki/skins/Mirage] Not a production skin; move to right section [integration/config] - 10https://gerrit.wikimedia.org/r/710626 (owner: 10Jforrester) [23:47:51] !log Zuul: [mediawiki/skins/Mirage] Not a production skin; move to right section [23:47:53] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [23:48:55] well, i got far, but not far enough [23:49:26] addshore: You're brilliant for trying. [23:49:27] for some reason the silly test cant find the binary, despite it being right there a line or so above [23:49:29] https://gitlab.wikimedia.org/releng/cli/-/jobs/268 [23:50:04] Curious. [23:50:14] yeah, i really dont get it, [23:50:21] Is the file somehow deleted? [23:50:23] ls shows it, it is executable, and then the bash script say no [23:50:39] Is the path magically re-writing away from . or something odd? [23:50:44] nah, the ls happens 1 command before the script tries to run [23:51:00] Yeah, but maybe ls triggers silent deletion in this universe? [23:51:43] (03CR) 10Jforrester: [C: 03+2] dockerfiles: [quibble-buster-php73-coverage] Add scripts for cover-skins [integration/config] - 10https://gerrit.wikimedia.org/r/709744 (https://phabricator.wikimedia.org/T287918) (owner: 10Reedy) [23:52:54] (03Merged) 10jenkins-bot: dockerfiles: [quibble-buster-php73-coverage] Add scripts for cover-skins [integration/config] - 10https://gerrit.wikimedia.org/r/709744 (https://phabricator.wikimedia.org/T287918) (owner: 10Reedy) [23:53:13] !log Docker: Publishing quibble-buster-php73-coverage 1.1.0 for T287918 [23:53:16] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [23:53:16] T287918: Enable coverage on all WMF deployed and MW bundled skins - https://phabricator.wikimedia.org/T287918 [23:59:53] James_F: it just gets more fun, i copy the binary, thats fine, then i try and run it, no no no https://gitlab.wikimedia.org/releng/cli/-/jobs/283