[15:05:57] phuedx|afk: joakino: jdlrobson: I finally looked at the task to generate Popups.git assets automagically ( https://phabricator.wikimedia.org/T158980 ). You guys are crazy and I like it :} [15:08:04] thanks hashar, i'll have a look, long response! :) [15:08:33] in side my rant there is a legitimate question [15:08:57] why not just: ResourcesModules[ext.popups][scripts] = resources/**/*.js ? :} [15:09:13] (not that extension registry supports such a thing, Ihaven't checked) [15:09:43] part of me believe we should have more magical convention other explicit settings [15:09:46] s/other/over/ [15:13:03] hashar: i'm commenting on that, TLDR scripts need to have a specific order that depends on their contents, so they need to be manually ordered [15:13:16] joakino: yeah I can imagine there is a good reason [15:13:28] or you guys would have done **/*.js :) [15:13:34] yeah [15:13:42] until we start having files like 00_index.js [15:13:46] 10_foobar.js [15:13:49] 99_last.js [15:13:50] ;D [15:13:57] haha [15:14:07] which is looks like decades old [15:14:12] 1999 style [15:14:53] but my point stand, I am not sure it is worth adding all the web pack complexity just to solve the trouble of adding entries in an array from time to time [15:15:02] but that is all your call. I don't dev so I don't know really :} [15:15:20] as for the deployment I think there is model that might work which I described in my comment. Keep master asset free [15:15:32] and manually build the wmf/xxx branch that would have the assets [15:15:55] until we figure out how to make that automatic [15:16:20] (the way we cut branch is via human assisted robots) [15:20:48] hashar: is the option 3. of having a job compile & commit daily not an option? you didn't mention it [15:22:49] ah yeah [15:23:17] that falls in my last paragraph: I don't have much time for implementation currently :/ [15:23:28] but surely if you get a script to automatize that [15:23:38] it would be easy to craft a jenkins job that invokes it for you [15:24:53] I am not too worried about the Jenkins part really. Once we know which steps / workflow to use , the actual implementation should be easy [15:26:12] hashar: what would the script need to do (steps)? I'll write it down [15:29:44] would it be build the thing, set up git branch, add changes, do a git review? [15:35:35] just trying to figure out how to help [15:40:02] joakino: that is to be figured out :-} [15:40:07] I have added Chad as a subscriber [15:40:10] he might shine in [15:40:20] s/shine/ whatever I really meant/ [15:40:26] ok, thanks hashar haha [15:40:27] bah [15:40:34] lmk now if I can do anything to help [15:40:57] for the wmf branches we do is use a make-wmf-branch script in mediawiki/tools/release.git [15:41:32] it is run on tuesday and basically for each repository listed (skins/extensions/mediawiki) ask Gerrit to cut a new branch wmf/XXXX having for HEAD the current master branch [15:41:39] i.e. we blindly cut what we are going to deploy [15:42:16] as Gerrit create branches for all repositories, Gerrit also update the submodules in mediawiki/extensions.git @ wmf/XXX [15:42:20] once all is done [15:42:29] hashar: the issue with that would be that it'd be weekly, so we wouldn't be able to check beta cluster for updates [15:42:53] we head to tin and clone mediawiki/{core,vendor,extensions,skins} at wmf/XXX run submodule update and blam all code is shipped [15:43:12] well beta would still run popups@master [15:43:29] yeah that's why keeping master updated with the compiled assets is easiest, right [15:43:37] but given the assets get stripped out of the master branch, we would need to adjust whatever job does the deploy/code update on beta [15:43:55] which potentially would be just adding a step: cd extensions/Popups; rm -fR assets; npm run build; [15:44:11] which is dirty [15:44:15] but easy to add to the job [15:44:42] aha [15:44:54] ok, let's discuss in the task and see what we end up with [15:45:23] the beta code update job is straightforward. The last build output is https://integration.wikimedia.org/ci/view/Beta/job/beta-code-update-eqiad/146432/console [15:45:35] there is some python script dealing with all the logic [15:46:26] one sure thing, we (releng), have to figure out a build step in between the branch cut and the code push to prod [15:46:48] so that would be something like: cut --> auto build -> clone on deployment servers [15:47:08] that auto build is done manually for now (cases: Wikidata, mediawiki/services/*/deploy ) [15:48:22] hashar: so you think modifying deploy process to build is better than keeping master updated with build assets? that'd be an interesting opinion on-task [15:48:45] seems more work but something that could set a process for other extensions [15:51:21] (definitely that is how other places do it) [15:53:43] joakino: or you can keep the assets in master yes, but I don't quite know how CI would manage to keep them updated [15:55:15] hashar: 👍 cool, that's very important, we don't want to do the wrong thing [15:55:26] the thing [15:55:27] is [15:55:42] if you send a patch A that tweak the setting but does not update the assets [15:55:45] A got a CR+2 [15:55:53] jobs are processed and are all fine [15:56:16] then either: we find a way to edit that commit before it lands, inject the asset in it, rebuild tests and finally merge [15:56:39] or: get the change merged, hold a lock to prevent other changes from landing, update assets, release lock [15:56:45] but maybe there is something easier [15:57:15] so imho either assets are committed together with the dependencies definition [15:57:21] or assets are extracted out somewhere else [15:57:28] aha [15:58:03] hashar: is there any git hook we could use to build before testing? [15:58:34] oh man there is that as well. Running tests bah [15:58:38] forgot about that part [15:58:49] the only affected in our case would be the selenium job [15:58:56] lol so many things [15:59:15] if you get rid of the assets, the MediaWiki core structure tests will complain because some RL module points to a non existing file [15:59:32] and the job would have to learn how to build the assets [15:59:40] damn that's true [15:59:41] (eg run cd extensions/Popups; npm build ) [15:59:48] too specific [15:59:55] well [16:00:02] that is yet another hack customization :D [16:00:20] jebus christ [16:00:25] so many thing [16:00:26] s [16:00:32] or maybe add a composer preinstall hook that triggers the npm build :D [16:01:24] so really what we lack is a system that actually build the code to run based on source repos [16:01:32] hashar: so composer install is being triggered on all the jobs? [16:01:40] hmm no [16:01:45] lel [16:02:10] for wikimedia deployed repos we use mediawiki/vendor instead of composer install [16:02:16] aha [16:02:26] then have a script that composer require the list of development dependencies (which are not in mediawiki/vendor ) [16:02:39] all of that is extremely bad and years of tech debt accumulated [16:02:47] i see [16:03:02] the idea is to make sure that master works with mediawiki/vendor [16:03:19] so later when we blindly cut the wmf/* branches for core/ext/vendor we know they are working together (more or less) [16:03:38] ;-( [16:04:13] you can tell I haven't thought too much about it :\ [16:04:58] hashar: nah, don't beat yourself [16:05:38] ok, let's see what comes out of the convo, it is interesting stuff [16:05:56] I am updating the task [16:08:17] thanks! [16:09:46] joakino: so yeah in short. Implementation is probably going to be easy. Defining requirements and fulfilling all the use cases is where the challenge reside [16:10:01] yep [17:26:03] off for today *wave* [18:29:30] jdlrobson: did we ship mediaviewer on mobilefrontend stable? [18:40:00] phuedx: did we have a trick on how to force oneself into the experiment bucket for the popups (or reading depth) schema, in production? [18:40:13] ...i vaguely recalled something about setting wgPopupsSchemaSamplingRate to 1 [18:42:14] HaeB: unfortunately not [18:42:16] ..but that's apparently not working because it is reset on pageload? [18:42:36] yeah, it's reset on pageload [18:43:12] or can we find and share a bucketed session id, and reset our own id to it? [18:43:16] currently, the staging server has wgPopupsSchemaSamplingRate = 1 by deffault [18:43:34] i think a nicer way would be to set it to one if ?debug=true [18:43:38] which is a small change [18:44:38] *nod* [18:54:04] HaeB: will make the change a little later when i can't sleep ;) [18:55:15] phuedx|zzZ: nice! (but please, do get your sleep ;) btw, same for readingdepth would be great too [19:31:15] nzr: "jdlrobson: did we ship mediaviewer on mobilefrontend stable?" huh? [21:03:42] <_Tuxedo> Hello! [21:04:04] <_Tuxedo> I have a MW 1.27.1 installation combined with MobileFrontend 1.0.0, which works great. [21:04:22] <_Tuxedo> I have a question maybe someone here knows the answer to: [21:05:31] <_Tuxedo> In my LocalSettings, I add some html after the content of all pages, by the following hook: [21:05:54] <_Tuxedo> $wgHooks['SkinAfterContent'][] = function ( &$data, Skin $skin ) { [21:05:55] <_Tuxedo> $data .= 'Some html

... bla below the content'; [21:05:57] <_Tuxedo> }; [21:06:27] <_Tuxedo> This is however not working in "Mobile view". [21:07:58] <_Tuxedo> Does anyone here know how and where I can add some generic HTML at the end of all MW pages to show in Mobile view? [21:56:57] hi _Tuxedo [21:57:13] im just familiarising myself with SkinAfterContent [21:57:20] it's possible that hook doesn't work with MobileFrontend [21:58:01] <_Tuxedo> Ok. [21:59:10] _Tuxedo: yeh that won't work. The Minerva skin doesn't output the content that this hook manipulates [21:59:18] let me see if there's another way you can do this [21:59:36] <_Tuxedo> Much appreciated! [22:00:49] _Tuxedo: unfortunately not seeing anything obvious.. Are you able to edit MobileFrontend/includes/skins/minerva.mustache ? [22:00:51] that might be your best option [22:01:14] you can add your html underneath {{{contenthtml}}} or underneath {{{contenthtml}}} [22:01:19] <_Tuxedo> Yes, I can edit the skins. [22:01:29] We could also add a bug to add support for that [22:01:32] it shouldn't be a big problem [22:01:43] but that should allow you in the meantime to add your html [22:01:46] lemme know if that works [22:02:07] <_Tuxedo> Thanks for the quick hack! I will try it. [22:28:32] <_Tuxedo> jdlrobson: Yes, it works well. Of course, it would be better done in LocalSettings as I have more than one wiki using the same skin and MW installation. Anyway, I just have write some domain-specific JS to work around it and remember not to remove the hack on next skin update. [22:28:52] <_Tuxedo> Thanks again for the quick solution.