[00:00:01] we need some better tools for that [00:00:29] I just have a script that creates "Test###" accounts until I ctrl+c it [00:00:31] tgr has been working on some good stuff for loading content pages easier than with wikidumps [00:00:34] like a `vagrant rebuild` (content export, vagrant destroy, vagrant up, content import) [00:00:50] or maybe we should just fix dumps :P [00:01:15] that wouldn't fix your users thing would it? [00:01:46] I had a vm I kept around a long time when I was working on SUL for that reason (wacky users and state for testing) [00:02:03] which is really a sign that I should have built something to recreate the test data [00:02:12] legoktm: you should make that a local role [00:02:53] ooooh yeah. we should have puppet defines to make that easier (creating initial users) [00:03:12] but a locak role to load an sql file should be pretty easy [00:03:21] *local [00:20:53] bd808: about https://phabricator.wikimedia.org/T90361#1072827, do you think it should be added to mwscript (which would make it depend on hiera) or just case-by-case? [00:22:03] I think the multiversion script needs to be able to figure that out actually [00:22:20] it knows what wiki it is running for so it just needs to setup the env [00:23:02] I wonder how this works on the cluster [00:23:03] (03PS1) 10Legoktm: Don't use a zuul trigger for -composer-security [integration/config] - 10https://gerrit.wikimedia.org/r/193526 [00:23:08] or is that a different mwscript? [00:24:00] cluster doesn't use detectServer() [00:24:11] and the scripts are slightly different [00:24:21] but detectServer() is what causes this problem [00:34:30] PROBLEM - Free space - all mounts on deployment-jobrunner01 is CRITICAL: CRITICAL: deployment-prep.deployment-jobrunner01.diskspace.root.byte_percentfree.value (<37.50%) [00:38:04] Project beta-scap-eqiad build #43205: FAILURE in 23 min: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/43205/ [01:35:02] 10Staging, 5Patch-For-Review: Setup staging-palladium as puppetmaster and saltmaster - https://phabricator.wikimedia.org/T88304#1075202 (10thcipriani) change 193545 is applied to staging-palladium. Formerly had to rely on role::salt::masters::labs::project_master class. After the patch is applied, salt::maste... [01:42:26] (03PS2) 10Legoktm: Don't use zuul variables to clone for -composer-security [integration/config] - 10https://gerrit.wikimedia.org/r/193526 [01:45:44] (03PS3) 10Legoktm: Don't use zuul variables to clone for -composer-security [integration/config] - 10https://gerrit.wikimedia.org/r/193526 [01:48:38] (03CR) 10Legoktm: "@hashar: I've deployed this, but could you check to make sure the way I'm using scm is ok? I couldn't find an alternative template to use " [integration/config] - 10https://gerrit.wikimedia.org/r/193526 (owner: 10Legoktm) [02:31:46] 10Continuous-Integration, 10VisualEditor, 5§ VisualEditor Q3 Blockers: Jenkins: Convert mwext qunit from grunt-contrib-qunit (PhantomJS) to grunt-karma (Chromium) - https://phabricator.wikimedia.org/T74063#1075258 (10Jdforrester-WMF) [02:34:05] bd808: it seems to me that you are kind of screwed if you set up a vagrant wiki where $db_name is not exactly ${wiki_name}wiki [02:34:29] it's hardcoded in a number of places [02:35:16] in which direction should that be fixed? I would get rid of dbname parameters, I don't think that flexibility has any use on vagrant [02:52:34] PROBLEM - Puppet staleness on deployment-urldownloader is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [43200.0] [03:05:43] Project browsertests-ZeroBanner-en.m.wikipedia.org-linux-phantomjs build #475: FAILURE in 42 sec: https://integration.wikimedia.org/ci/job/browsertests-ZeroBanner-en.m.wikipedia.org-linux-phantomjs/475/ [03:31:41] Yippee, build fixed! [03:31:42] Project browsertests-Core-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #507: FIXED in 12 min: https://integration.wikimedia.org/ci/job/browsertests-Core-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/507/ [04:04:03] Yippee, build fixed! [04:04:04] Project browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-chrome-monobook-sauce build #323: FIXED in 32 min: https://integration.wikimedia.org/ci/job/browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-chrome-monobook-sauce/323/ [04:13:14] (03CR) 10AndyRussG: [C: 031] WIP Created the first Android centralNotice Jenkins job (031 comment) [integration/config] - 10https://gerrit.wikimedia.org/r/193361 (owner: 10Zfilipin) [04:14:25] Yippee, build fixed! [04:14:25] Project browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-firefox-monobook-sauce build #339: FIXED in 42 min: https://integration.wikimedia.org/ci/job/browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-firefox-monobook-sauce/339/ [04:42:15] (03PS1) 10Legoktm: Use composer for experimental mediawiki-phpunit-{phpflavor}-composer jobs [integration/config] - 10https://gerrit.wikimedia.org/r/193555 (https://phabricator.wikimedia.org/T90303) [04:45:05] (03PS2) 10AndyRussG: WIP Created the first Android centralNotice Jenkins job [integration/config] - 10https://gerrit.wikimedia.org/r/193361 (https://phabricator.wikimedia.org/T86092) (owner: 10Zfilipin) [04:47:30] (03CR) 10AndyRussG: "(Just added Phab task to the commit message...)" [integration/config] - 10https://gerrit.wikimedia.org/r/193361 (https://phabricator.wikimedia.org/T86092) (owner: 10Zfilipin) [04:53:49] (03PS1) 10AndyRussG: CentralNotice browser tests: even more platforms and browsers [integration/config] - 10https://gerrit.wikimedia.org/r/193556 (https://phabricator.wikimedia.org/T86092) [05:14:00] Yippee, build fixed! [05:14:00] Project browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-windows_8-internet_explorer-sauce build #493: FIXED in 33 min: https://integration.wikimedia.org/ci/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-windows_8-internet_explorer-sauce/493/ [05:16:43] Yippee, build fixed! [05:16:43] Project browsertests-MultimediaViewer-mediawiki.org-linux-firefox-sauce build #494: FIXED in 2 min 50 sec: https://integration.wikimedia.org/ci/job/browsertests-MultimediaViewer-mediawiki.org-linux-firefox-sauce/494/ [05:19:07] Yippee, build fixed! [05:19:08] Project browsertests-CentralAuth-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #8: FIXED in 2 min 24 sec: https://integration.wikimedia.org/ci/job/browsertests-CentralAuth-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/8/ [05:30:50] (03PS3) 10Sumit: Sniff to detect text before first opening php tag [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/192201 (https://phabricator.wikimedia.org/T46875) [05:33:50] Yippee, build fixed! [05:33:51] Project browsertests-UniversalLanguageSelector-commons.wikimedia.beta.wmflabs.org-linux-firefox-sauce build #488: FIXED in 14 min: https://integration.wikimedia.org/ci/job/browsertests-UniversalLanguageSelector-commons.wikimedia.beta.wmflabs.org-linux-firefox-sauce/488/ [05:48:49] Yippee, build fixed! [05:48:49] Project browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-windows_7-internet_explorer-9-sauce build #339: FIXED in 41 min: https://integration.wikimedia.org/ci/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-windows_7-internet_explorer-9-sauce/339/ [06:36:22] Yippee, build fixed! [06:36:23] Project beta-scap-eqiad build #43242: FIXED in 2 min 22 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/43242/ [06:54:26] RECOVERY - Free space - all mounts on deployment-jobrunner01 is OK: OK: All targets OK [08:25:35] 10Quality-Assurance, 10Gather, 5Patch-For-Review: Setup Gather browser tests Jenkins job - https://phabricator.wikimedia.org/T91082#1075463 (10hashar) [08:26:51] 10Beta-Cluster: beta: table centralauth/localnames is crashed on 10.68.16.193 (can not login on beta) - https://phabricator.wikimedia.org/T91084#1075464 (10hashar) p:5Triage>3Unbreak! [08:35:38] 10Beta-Cluster, 5Patch-For-Review, 7Puppet: Puppet failures on deployment-bastion - https://phabricator.wikimedia.org/T75520#1075468 (10hashar) 5Open>3Resolved It seems so [08:39:53] 10Beta-Cluster: beta: table centralauth/localnames is crashed on 10.68.16.193 (can not login on beta) - https://phabricator.wikimedia.org/T91084#1075470 (10hashar) [08:39:54] 10Beta-Cluster: Crashed tables in deployment-db1 - https://phabricator.wikimedia.org/T91055#1075471 (10hashar) [08:40:16] 10Beta-Cluster: Crashed tables in deployment-db1 (can not login on beta) - https://phabricator.wikimedia.org/T91055#1075473 (10hashar) p:5Triage>3High [10:42:19] (03PS3) 10Zfilipin: add Christoph Fischer to Wikidata notifications [integration/config] - 10https://gerrit.wikimedia.org/r/193379 (owner: 10WMDE-Fisch) [10:42:43] (03CR) 10Zfilipin: [C: 032] "Please deploy the changes to Jenkins. Let me know if you need help with that." [integration/config] - 10https://gerrit.wikimedia.org/r/193379 (owner: 10WMDE-Fisch) [10:49:57] (03Merged) 10jenkins-bot: add Christoph Fischer to Wikidata notifications [integration/config] - 10https://gerrit.wikimedia.org/r/193379 (owner: 10WMDE-Fisch) [10:54:42] Project beta-scap-eqiad build #43268: FAILURE in 44 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/43268/ [11:06:59] 10Continuous-Integration, 6Release-Engineering, 7Jenkins: Deleted unused browsertests builder from integration-config/jjb/macro.yaml - https://phabricator.wikimedia.org/T91161#1075514 (10zeljkofilipin) 3NEW a:3zeljkofilipin [11:14:50] Yippee, build fixed! [11:14:50] Project beta-scap-eqiad build #43270: FIXED in 54 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/43270/ [11:16:28] 10Continuous-Integration, 6Release-Engineering, 7Jenkins: Deleted unused browsertests builder from integration-config/jjb/macro.yaml - https://phabricator.wikimedia.org/T91161#1075548 (10zeljkofilipin) [11:20:12] (03PS1) 10Zfilipin: WIP T91161 [integration/config] - 10https://gerrit.wikimedia.org/r/193566 (https://phabricator.wikimedia.org/T91161) [11:35:40] 10Continuous-Integration, 6Release-Engineering, 7Jenkins, 5Patch-For-Review: Deleted unused browsertests builder from integration-config/jjb/macro.yaml - https://phabricator.wikimedia.org/T91161#1075570 (10zeljkofilipin) [11:37:26] 10Continuous-Integration, 6Release-Engineering, 7Jenkins, 5Patch-For-Review: Deleted unused browsertests builder from integration-config/jjb/macro.yaml - https://phabricator.wikimedia.org/T91161#1075514 (10zeljkofilipin) [11:39:12] 10Continuous-Integration, 6Release-Engineering, 7Jenkins, 5Patch-For-Review: Deleted unused browsertests builder from integration-config/jjb/macro.yaml - https://phabricator.wikimedia.org/T91161#1075573 (10zeljkofilipin) [11:44:49] 10Continuous-Integration, 6Release-Engineering, 7Jenkins, 5Patch-For-Review: Deleted unused browsertests Jenkins jobs - https://phabricator.wikimedia.org/T91161#1075574 (10zeljkofilipin) [11:45:16] 10Continuous-Integration, 6Release-Engineering, 7Jenkins, 5Patch-For-Review: Delete unused mwext-browsertests Jenkins jobs - https://phabricator.wikimedia.org/T91161#1075514 (10zeljkofilipin) [11:45:48] (03PS2) 10Zfilipin: Delete unused mwext-browsertests Jenkins jobs [integration/config] - 10https://gerrit.wikimedia.org/r/193566 (https://phabricator.wikimedia.org/T91161) [11:46:07] (03PS3) 10Zfilipin: Delete unused mwext-browsertests Jenkins jobs [integration/config] - 10https://gerrit.wikimedia.org/r/193566 (https://phabricator.wikimedia.org/T91161) [11:47:23] (03PS4) 10Zfilipin: Delete unused mwext-browsertests Jenkins jobs [integration/config] - 10https://gerrit.wikimedia.org/r/193566 (https://phabricator.wikimedia.org/T91161) [11:47:35] (03PS5) 10Zfilipin: Delete unused mwext-browsertests Jenkins jobs [integration/config] - 10https://gerrit.wikimedia.org/r/193566 (https://phabricator.wikimedia.org/T91161) [11:50:38] 10Continuous-Integration, 6Release-Engineering, 7Jenkins, 5Patch-For-Review: Delete unused mwext-browsertests Jenkins jobs - https://phabricator.wikimedia.org/T91161#1075577 (10zeljkofilipin) 5Open>3Resolved [11:51:58] 6Release-Engineering, 7Documentation: Document RuboCop workflow - https://phabricator.wikimedia.org/T1368#1075578 (10zeljkofilipin) I wrote a blog post recently with generic RuboCop workflow, not specific to Wikimedia. I have to document Wikimedia specific things. [12:12:38] (03Abandoned) 10Zfilipin: WIP cleanup [integration/config] - 10https://gerrit.wikimedia.org/r/193350 (owner: 10Zfilipin) [12:45:04] 10Continuous-Integration, 6Release-Engineering, 7Jenkins: Refactor VisualEditor JJB builder for production status browsertest to use Cucumber tag instead of calling a file directly - https://phabricator.wikimedia.org/T90423#1075607 (10zeljkofilipin) [13:51:03] Project browsertests-VisualEditor-production-linux-firefox-sauce-T90423 build #1: SUCCESS in 53 sec: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-production-linux-firefox-sauce-T90423/1/ [13:53:45] (03CR) 10Hashar: [C: 04-1] "Two jobs are still triggered in Zuul and have some non voting configuration. You will want to remove them:" [integration/config] - 10https://gerrit.wikimedia.org/r/193566 (https://phabricator.wikimedia.org/T91161) (owner: 10Zfilipin) [13:56:04] (03CR) 10Hashar: [C: 031] Setup Gather browser tests job [integration/config] - 10https://gerrit.wikimedia.org/r/193393 (https://phabricator.wikimedia.org/T91082) (owner: 10Jdlrobson) [14:01:35] (03CR) 10Hashar: [C: 031] "Zuul supports triggering jobs based on a timer, but the time definition is applied on the pipeline, not on a per job basis. But eventually" [integration/config] - 10https://gerrit.wikimedia.org/r/193526 (owner: 10Legoktm) [14:37:00] Yippee, build fixed! [14:37:00] Project browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce build #28: FIXED in 8 min 59 sec: https://integration.wikimedia.org/ci/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/28/ [15:25:51] (03PS1) 10Zfilipin: Refactor VisualEditor JJB builder for production status browsertest to use Cucumber tag instead of calling a file directly [integration/config] - 10https://gerrit.wikimedia.org/r/193577 (https://phabricator.wikimedia.org/T90423) [15:26:41] (03PS2) 10Zfilipin: Refactor VisualEditor JJB builder for production status browsertest [integration/config] - 10https://gerrit.wikimedia.org/r/193577 (https://phabricator.wikimedia.org/T90423) [15:32:31] (03CR) 10Zfilipin: "See also https://gerrit.wikimedia.org/r/#/c/193579/" [integration/config] - 10https://gerrit.wikimedia.org/r/193577 (https://phabricator.wikimedia.org/T90423) (owner: 10Zfilipin) [15:55:11] Krenair: If CI has issues and there are documented procedures to "mitigate" them (e.g. Zuul deadlock) it's fine to do them. If they don't have a task already (unlikely if they've been around long enough to have doucmented workarounds), then we should file a task for sure, but my "policy" is more about situations where random stuff breaks, antoine or myself has to jump in and figure out what's up and [15:55:11] fix it - that we should not do so without filing a bug unless the problem was directly caused by something we did by accident just earlier that day. [15:55:35] e.g. if stuff broke without clear cause and it was worked around by resetting something, that didn't happen by itself and must not be forgotten because it will inevitably happen again. [15:55:44] People are good at forgetting :) [17:14:41] Project beta-scap-eqiad build #43306: FAILURE in 39 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/43306/ [17:34:55] Yippee, build fixed! [17:34:55] Project beta-scap-eqiad build #43308: FIXED in 53 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/43308/ [17:40:58] (03PS1) 10Krinkle: Remove mediawiki-core-regression-* jobs [integration/config] - 10https://gerrit.wikimedia.org/r/193583 (https://phabricator.wikimedia.org/T88018) [17:41:17] (03CR) 10Krinkle: "Not sure if this removes too much. See T88018 for details." [integration/config] - 10https://gerrit.wikimedia.org/r/193583 (https://phabricator.wikimedia.org/T88018) (owner: 10Krinkle) [17:43:01] Hi Krinkle how's it going? Got a sec for a quick question? I was thinking of a way to run CentralNotice QUnit tests regularly on different platforms and browsers... I came up with the twisted plan of making a cucumber test that checks for a no failures result, and running that on SauceLabs... Željko suggested that before going ahead I ask you or Antoine, though, since he thought you might know about or be working on [17:43:01] something better for the same purpose :) [17:43:42] AndyRussG: Yeah, using selenium seems that seems a bit more complex than needed. [17:43:46] This is exactly what Karma does. [17:44:07] What's Karma? [17:44:09] * AndyRussG googles [17:44:16] It uses webdriver to connect to local browsers and/or sauce labs, performs qunit and uses data driven (e.g. callbacks and events, not DOM checking or hacky regexes to try and figure it it passed) [17:44:37] AndyRussG: I'd recommend just running the default qunit macro in Jenkins for now [17:44:45] It'll migrate to karma when the rest does [17:45:10] Which only runs PhantomJS at the moment, though that code has been 99% rewritten and about to be replaced by I'm finishing up the last bits [17:45:17] oojs, oojs ui and VisualEditor already use this [17:45:23] For cross-browser compatibility [17:46:13] AndyRussG: See https://integration.wikimedia.org/ci/job/oojs-core-npm/434/console for example [17:46:24] uses local Firefox and Chrome, then saucelabs for more browsers [17:47:18] AndyRussG: I assume the tests are currently passing on Special:JavaScriptTest/qunit when run locally for you in a real browser? [17:47:38] https://www.mediawiki.org/wiki/Manual:JavaScript_unit_testing [17:48:01] Krinkle: yep passing nicely. That oojs job does look nice [17:48:13] AndyRussG: If and when they are, just file a phab task asking for -qunit to be enabled for the relevant git repo and we'll do the rest. [17:48:56] Since most of it has been abstracted into a simple job template, a patch would also be very welcome. [17:49:00] Krinkle: fantastic! I mean qunit already runs on every commit for CentralNotice [17:49:09] It's just 2 lines in config/jjb and 1 line in config/zuul [17:49:11] Right [17:49:59] Krinkle: cool...! So I could look for the setup for oojs to copy that? [17:50:08] There's currently stability issues with Trusty causing local mediawiki installs to time out when reached from an apache (as opposed to phpunit via command line) [17:50:35] Hence the standard -qunit template still uses production slaves with phantomjs (and no karma) instead of Karma on labs slaves and saucelabs [17:51:00] AndyRussG: Nope, the setup oojs and others have is for standalone projects where the test would be initiated from the local repo's npm-test pipeline [17:51:14] however for mediawiki extensions, just like with phpunit tests, those are initiated from within mediawiki core [17:51:39] Hmmm [17:51:41] e.g. there is no phpunit entry point in an extension repo, the repo registers them with core and you run the tests from there. [17:51:44] same for qunit [17:51:49] so there's nothing to add to your repo [17:51:58] when mediawiki-core uses it, extension repos do as well. [17:52:01] They just add tests. [17:52:29] Hmm [17:53:24] The test runners for mediawiki are in mediawiki-core. Extensions register additional test suites. There is no logic of any kind to "run" phpunit or qunit in an extension repo. [17:54:00] Right, that's what we do, we register two test suites via a hook somewhere or other [17:57:43] Krinkle: So... just to check that I understand... I'll add stuff in config/jjb and config/zuul to have the qunit tests run periodically (even without commits), and even though initially they'll run just PhantomJS for now, it'll soon be ported to sauce? I can try to figure out what to add, and if I get lost I can add the Phab task as you suggest... [17:57:57] I'm just getting into JJB but it sounds like a fun treasure hunt [17:58:05] Does that make sense? [17:58:08] AndyRussG: Note that karma/saucelabs also takes care of setting up a tunnel so that you're testing the latest master as set up by Jenkins on the VM. [17:58:09] Thanks a ton, BTW :) [17:58:10] No connection to testwiki or beta. [17:58:19] AndyRussG: That config stuff I mentioned you already have. [17:58:31] the qunit template will be using karma soon. [17:58:36] There's nothing to do for now [17:58:51] Krinkle: ah OK! ... heh well that's easier :) [17:58:52] It will not run periodically, however. [17:58:57] Ah hmmm [17:59:01] just on commits? [17:59:04] Yeah [17:59:08] Why would you want to run it periodically? [17:59:11] Updating browsers? [17:59:39] Yeah kinda like what we do with sauce/cucumber, if stuff starts failing you get some e-mail even if you haven't been commiting [18:00:48] AndyRussG: It can be triggered periodically from an additional schedule. 1 line in jjb [18:00:54] No problem. [18:01:03] Krinkle: cool! [18:01:09] For CentralNotice we have a pretty big set of test fixtures that run through different scenarios of banner targetting [18:01:12] Though if it becomes part of the standard extension stack there's no need. It'll run naturally often enough [18:01:15] e.g. on mediawiki core commits [18:01:17] and wmf branch creation [18:01:32] Krinkle: ah OK [18:03:16] Yeah so those test fixtures check that the JS that participates in targeting users for banners [18:03:32] AndyRussG: can you point me to the tests? [18:03:36] Curious how they're implemented. [18:03:44] Krinkle: u bet! one sec :) [18:03:52] For them to be considered for the standard stack they'd have to be atomic and relatively fast. [18:04:45] https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FCentralNotice/de5fc1b850ad15d7b4c3ad750c4bfd99b46ff567/tests%2Fqunit%2Fext.centralNotice.bannerController.lib%2FbannerController.lib.tests.js [18:05:06] Krinkle: they're not yet very atomic, a bit more integration-y than unit-y for now [18:05:45] Here are the fixtures, which are also used by PHPUnit: https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FCentralNotice/de5fc1b850ad15d7b4c3ad750c4bfd99b46ff567/tests%2Fdata [18:06:06] Yippee, build fixed! [18:06:07] Project browsertests-ZeroBanner-en.m.wikipedia.org-linux-phantomjs build #476: FIXED in 1 min 5 sec: https://integration.wikimedia.org/ci/job/browsertests-ZeroBanner-en.m.wikipedia.org-linux-phantomjs/476/ [18:06:14] They are quite fast, tho [18:07:37] k. checking now [18:08:54] We're gonna be doing a bit more refactoring of this code for some new requirements of Fundraising, so that's why we're holding off on more atomic tests [18:10:09] AndyRussG: Use npm install && grunt qunit from the MediaWiki core directory to run QUnit tests from the command-line in you local Chrome browser. [18:10:11] However even when we do that, I think even then, the integration level of running these fixtures through the whole JS-banner-targetting procedure will be useful [18:10:22] That is essentially what we'll be using in Jenkins [18:10:36] It requires you set an env variable to indicate where your local mediawiki install is. [18:11:00] And then uses karma to pop open your local Chrome install, run the tests programmatically and extracts the tests results from qunit event emitter [18:11:10] (using web-driver underneath) [18:11:22] wooo sweet [18:11:37] I landed that in MediaWiki earlier this month. It works great locally already [18:12:00] No longer requires any Jenkins-specific utilities or settings. [18:13:22] AndyRussG: Running locally gives me a syntax error as PHP runtime for js loading is interrupted with a php error [18:13:24]
[18:13:24] Warning: No route to fetch banner choice data configured. [Called from CNBannerChoiceDataResourceLoaderModule::getChoices in /Users/krinkle/Development/mediawiki/extensions/CentralNotice/includes/CNBannerChoiceDataResourceLoaderModule.php at line 57] in /Users/krinkle/Development/mediawiki/core/includes/debug/MWDebug.php on line 300
[18:13:56] Ideally running unit tests should not require any local configuration but mock or default accordingly [18:14:05] Ah right, yes [18:14:27] We do already have some mock config in there in fact [18:14:51] Not sure why you're getting that error to just run QUnit but I'll check it out [18:15:23] So just to make sure I understand... running with npm and grunt qunit locally... and applying any fixes needed... will ensure that we're ready to be on the train when that hits Jenkins? [18:15:40] Yep [18:16:03] AndyRussG: Once infra issues are resolved, mwext-{}-qunit will use npm install/grunt qunit with karma [18:16:10] if things are not passing under that, build will be failing. [18:16:26] There'll be an announcement before that of course [18:16:31] You can also choose to opt-in now [18:16:50] Krinkle: right got it :) [18:16:58] mediawiki-core and VisualEditor have a non-voting qunit-karma pipeline already that runs it in Chrome with Karma in labs instead of legacy PhantomJS without karma. [18:17:17] It might be failing from time to time due to a race condition I'm working on but may be useful already [18:17:43] It'll give you coverage in at least one real and up to date browser [18:17:55] (as opposed to a 4-year old fake browser) [18:18:08] heh right [18:18:32] We've got the labs instances pinned to install latest stable Chromium from Ubuntu [18:18:41] e.g. 40 right now [18:19:10] Yeah that sounds like a fine start [18:19:44] It makes sense that browser platform testing should be coordinated site-wide of course [18:19:50] https://github.com/wikimedia/integration-config/blob/effb34e5ce56a7ce24ff33a92252b388f30883a4/jjb/mediawiki-extensions.yaml#L150 [18:19:54] I already created a job-template for it [18:20:06] Feel free to add it for CentralNotice [18:20:19] Around this area https://github.com/wikimedia/integration-config/blob/effb34e5ce56a7ce24ff33a92252b388f30883a4/jjb/mediawiki-extensions.yaml#L1092-L1094 [18:22:43] Right! I see VE and UploadWizard there... [18:23:01] This will be of course after making sure that npm grunt is happy... [18:25:40] Krinkle: cool sounds like a plan (unless the above doesn't make sense and I've misunderstood stuff, not unlikely heh) [18:28:56] Krinkle: thanks so much! [18:29:12] UploadWizard actually doesn't use this yet. [18:29:29] The mwext-name-qunit-karma template is only used by VisualEditor right now. [18:30:10] UploadWizard and CentralNotice do both use '{name}-{ext-name}-qunit' [18:30:20] You'd add an item there for '{name}-{ext-name}-qunit-karma' passing it CentralNotice [18:30:48] and then a line in zuul/layout to set it to voting:false and add it to your test pipeline [18:30:58] https://github.com/wikimedia/integration-config/blob/effb34e5ce56a7ce24ff33a92252b388f30883a4/jjb/mediawiki-extensions.yaml#L1171-1180 ? [18:31:20] -qunit is the legacy grunt-contrib job using phantomjs [18:31:31] The same that CentralNotice uses here https://github.com/wikimedia/integration-config/blob/effb34e5ce56a7ce24ff33a92252b388f30883a4/jjb/mediawiki-extensions.yaml#L1093-L1095 [18:31:31] Ah OK [18:31:55] https://github.com/wikimedia/integration-config/blob/effb34e5ce56a7ce24ff33a92252b388f30883a4/jjb/mediawiki-extensions.yaml#L130-L164 [18:32:13] I've abstracted the underlying logic to share everything and only the 'qunit' and 'qunit-macro' differs. [18:32:16] I also see npm for VE and UW [18:32:22] Yep [18:32:33] That's the tests run from within the repo that do not depend in mediawiki-core [18:32:38] e.g. your jshint, jscs tests [18:32:42] Ah OK [18:33:02] -jslint is deprecated [18:33:11] K [18:33:19] Can't be upgraded and has scalability issues. Much easier to use -npm so that people can run it locally [18:33:27] and you control when the jshint binary is upgraded [18:33:43] https://www.mediawiki.org/wiki/Continuous_integration/Test_entry_points [18:34:12] We're also deprecating the -phpcs and -phpunit jobs in favour of -composer [18:34:52] Thus moving ownership and control over what and how tests run back to the individual projects. [18:34:53] Ah fun [18:35:43] so instead of having to update Jenkins and add new tests, you'd just update composer.json and package.json to use whatever framework you like. E.g. jshint, phpcs, jscs, phpunit etc. [18:35:50] Should make things a lot easier [18:36:22] Also with regards to older branches. Right now things often break when backporting commits since the old branch doesn't pass the "new" test jobs. Whereas if this is specified in the repo and branch, things stay together. [18:36:29] And again, makes it so easy to run locally for developers [18:36:47] Right that makes sense [18:36:47] Nice... yeah I haven't been following the composer stuff too much, but I don't see anything related in CentralNotice yet [18:36:48] you'll have the confidence that running 'npm test' (or composer test) does the same that Jenkins does [18:37:11] without needing to know which version jshint is installed on Jenkins. [18:37:17] and same for phpunit/phpcs etc. [18:38:51] cool... yeah we have a moderately decent phpunit suit though there is some cruft [18:39:05] also uses the same test fixtures [18:41:25] I guess I haven't run across issues with PHPUnit updates yet, but it makes sense to take that into account [18:42:00] Actually now that I think of it there is some silly legacy issue that limits the ways you can run them locally... [18:42:56] There's still tons improvements to do on the codebase, and at the same time we have to keep up with new FR needs [18:45:14] So with tests we have to find a balance betwen making sure things keep working while we change and add things, and not spending too much time writing tests that depend on stuff that will change soon [18:46:17] (03CR) 10Sumit: "Added the passing test" [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/192201 (https://phabricator.wikimedia.org/T46875) (owner: 10Sumit) [22:36:32] PROBLEM - Free space - all mounts on deployment-jobrunner01 is CRITICAL: CRITICAL: deployment-prep.deployment-jobrunner01.diskspace.root.byte_percentfree.value (<33.33%) [23:35:01] Project beta-scap-eqiad build #43344: FAILURE in 39 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/43344/ [23:54:59] Yippee, build fixed! [23:55:00] Project beta-scap-eqiad build #43346: FIXED in 57 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/43346/