[00:04:47] marxarelli: I made a sketch of what I wanted to do: http://etherpad.wikimedia.org/p/uw-cucumber-sketch [00:05:14] functionally it's the same thing, I would just like to keep step definitions nice and short [00:05:28] given that every test will have to repeat them [00:05:53] is that a bad idea? [00:09:25] tgr: given that the existing steps have not changed in ~2 years I'm not sure of the utility of abstracting what exists, although it can be done in several ways https://github.com/wikimedia/mediawiki-extensions-UploadWizard/blob/master/tests/browser/features/step_definitions/upload_wizard_steps.rb marxarelli [00:10:47] (03CR) 10Ori.livneh: "I think we should use travis for 5.3 compat testing and remove this from gate-and-submit as well. We used Travis for HHVM compat testing b" [integration/config] - 10https://gerrit.wikimedia.org/r/187904 (owner: 10Hashar) [00:11:09] tgr: i don't think it's a bad idea. maybe chrismcmahon and i disagree on that :) [00:11:20] heh. :-) [00:11:39] chrismcmahon: we are about to add a few more tests since Mark is now working on refactoring the huge mess that UW step classes are, and the original tests don't cover a lot of exotic failure options [00:12:47] the original test included testing each step in a single long walkthrough, for some of the new tests that won't make sense because you need special files etc [00:14:45] tgr: what I'd like to do is to have the Scenario for these new tests available. If we had those, we could figure out the best way to implement them. [00:15:38] chrismcmahon: there are a few at the bottom of http://etherpad.wikimedia.org/p/uploadwizard-browser-tests [00:17:26] so "When I am on the file upload step" could easily re-use existing steps [00:18:39] the way this does https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/master/modules/ve-mw/tests/browser/features/step_definitions/multiedit_workflow_steps.rb [00:18:47] true, that step is not problematic [00:20:20] the latter steps will be [00:20:42] but I guess not trying to abstract things until I have a concrete need for it is solid advice :) [00:20:53] other than that, the only new things I see are generating a large file and controlling what user the test uses [00:21:34] yeah, I am a big fan of doing the simplest possible thing first [00:25:29] my one sort of guiding design principle is to make sure to keep the separation intact between what is part of the page (PageObject), what is an action taken on that page, and what is the appropriate description of what the test does. [00:25:48] beyond that I try not to have strong opinions [00:28:10] see you tomorrow... [00:40:26] tgr: fwiw, cucumber steps are also abstractions, but i think chris's arguments are completely valid. he's also maintained a lot more of these tests over the years, so going with his advice is smart :) [00:41:42] yeah, he is probably right about not worrying about it until we start writing a test where it is actually useful [00:41:52] a tend to overabstract things [00:42:16] s/a/I/ [00:42:20] changing the topic... [00:42:40] are these tests guaranteed to be non-parallel? [00:43:11] tgr: no [00:43:17] because the original test manipulates a user pref [00:43:34] which influences which UploadWizard step comes up at start [00:45:05] can different features share step definitions? [00:45:13] tgr: we're looking into ways to make the environment more isolated and tests more atomic [00:45:51] but it's something you should account for in tests if you can, by naming articles and such with random hashes [00:46:04] not much we can do about the user preferences at this point though [00:46:42] tgr: all step definitions are shared. you should try to organize them by function rather than by feature [00:47:25] tgr: https://github.com/cucumber/cucumber/wiki/Step-Organisation [00:47:50] thanks [00:48:08] I guess I hsould read those docs before asking RTFM questions :) [00:48:11] tgr: yw! [00:48:16] haha, it's ok [00:48:42] we need to organize our own docs better to link upstream [00:48:53] i've tried to do that in the 1.0.0.pre.1 readme [00:49:18] tgr: https://doc.wikimedia.org/rubygems/mediawiki-selenium/index.html [00:51:20] ok, i'm out. more house-buying chores to do... [01:14:41] Project beta-scap-eqiad build #41458: FAILURE in 39 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/41458/ [01:34:53] Yippee, build fixed! [01:34:54] Project beta-scap-eqiad build #41460: FIXED in 52 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/41460/ [02:13:26] 3MediaWiki-Unit-tests, Continuous-Integration: Fix flaky unit test "TextPassDumperTest::testCheckpointGzip" - https://phabricator.wikimedia.org/T70653#738146 (10Krinkle) Test has been disabled. The #contint blocked has been solved. Retriaged as MediaWiki core issue to fix this unit test. [02:19:12] (03CR) 10Krinkle: [C: 031] "Compiling/deploying (will take a while)" [integration/config] - 10https://gerrit.wikimedia.org/r/166071 (https://phabricator.wikimedia.org/T50420) (owner: 10Jforrester) [04:15:45] Yippee, build fixed! [04:15:45] Project browsertests-UploadWizard-commons.wikimedia.beta.wmflabs.org-linux-firefox-sauce build #480: FIXED in 14 min: https://integration.wikimedia.org/ci/job/browsertests-UploadWizard-commons.wikimedia.beta.wmflabs.org-linux-firefox-sauce/480/ [06:36:12] RECOVERY - Free space - all mounts on deployment-bastion is OK: OK: All targets OK [06:44:05] PROBLEM - Puppet failure on deployment-cache-mobile03 is CRITICAL: CRITICAL: 62.50% of data above the critical threshold [0.0] [07:09:02] RECOVERY - Puppet failure on deployment-cache-mobile03 is OK: OK: Less than 1.00% above the threshold [0.0] [07:34:39] Project beta-scap-eqiad build #41497: FAILURE in 43 Seg : https://integration.wikimedia.org/ci/job/beta-scap-eqiad/41497/ [07:44:38] (03CR) 10Krinkle: [C: 032] Clean up phpcs macros and jobs (remove strict/lenient split) [integration/config] - 10https://gerrit.wikimedia.org/r/166071 (https://phabricator.wikimedia.org/T50420) (owner: 10Jforrester) [07:51:24] (03Merged) 10jenkins-bot: Clean up phpcs macros and jobs (remove strict/lenient split) [integration/config] - 10https://gerrit.wikimedia.org/r/166071 (https://phabricator.wikimedia.org/T50420) (owner: 10Jforrester) [07:54:51] Yippee, build fixed! [07:54:52] Project beta-scap-eqiad build #41499: FIXED in 54 Seg : https://integration.wikimedia.org/ci/job/beta-scap-eqiad/41499/ [08:07:19] 3MediaWiki-Unit-tests, Continuous-Integration: Make PHPUnit tests runnable without installing MediaWiki (tracking) - https://phabricator.wikimedia.org/T89432#1036139 (10Krinkle) 3NEW [08:08:30] 3MediaWiki-Unit-tests, Continuous-Integration: Make QUnit tests runnable without a MediaWiki install (tracking) - https://phabricator.wikimedia.org/T89433#1036148 (10Krinkle) 3NEW a:3Krinkle [08:13:01] 3MediaWiki-Unit-tests, Continuous-Integration: Make QUnit tests runnable without a MediaWiki install (tracking) - https://phabricator.wikimedia.org/T89433#1036158 (10Krinkle) [09:07:18] PROBLEM - Puppet staleness on deployment-eventlogging02 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [43200.0] [10:13:59] 3MediaWiki-Unit-tests, Continuous-Integration: Make PHPUnit tests runnable without installing MediaWiki (tracking) - https://phabricator.wikimedia.org/T89432#1036139 (10hashar) I have raised the subject to the MediaWiki core team list at https://lists.wikimedia.org/pipermail/mediawiki-core/2015-February/000147.h... [11:11:57] PROBLEM - Puppet failure on deployment-cxserver03 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [11:16:56] RECOVERY - Puppet failure on deployment-cxserver03 is OK: OK: Less than 1.00% above the threshold [0.0] [12:37:35] PROBLEM - SSH on deployment-lucid-salt is CRITICAL: Connection refused [13:05:07] !log Reloading Zuul to deploy I0eaf2085576165b [13:05:10] Logged the message, Master [13:54:49] Project beta-scap-eqiad build #41533: FAILURE in 42 Seg : https://integration.wikimedia.org/ci/job/beta-scap-eqiad/41533/ [14:03:42] !log Jenkins UI stuck in Spanish. Resetting configuration. [14:03:44] Logged the message, Master [14:14:54] Yippee, build fixed! [14:14:55] Project beta-scap-eqiad build #41535: FIXED in 56 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/41535/ [14:40:03] PROBLEM - Puppet failure on deployment-cache-mobile03 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [14:40:55] PROBLEM - Puppet failure on deployment-cache-upload02 is CRITICAL: CRITICAL: 77.78% of data above the critical threshold [0.0] [14:46:29] PROBLEM - Puppet failure on deployment-cache-text02 is CRITICAL: CRITICAL: 75.00% of data above the critical threshold [0.0] [14:56:17] PROBLEM - Puppet failure on deployment-cache-bits01 is CRITICAL: CRITICAL: 75.00% of data above the critical threshold [0.0] [18:32:55] Yippee, build fixed! [18:32:55] Project browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce build #504: FIXED in 31 min: https://integration.wikimedia.org/ci/job/browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/504/ [18:33:40] fwiw, we missed one password change on beta labs, made that ^^ fail for a couple of builds [18:51:01] Yippee, build fixed! [18:51:01] Project browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #538: FIXED in 40 min: https://integration.wikimedia.org/ci/job/browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/538/ [19:07:22] Yippee, build fixed! [19:07:23] Project browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-chrome-monobook-sauce build #295: FIXED in 33 min: https://integration.wikimedia.org/ci/job/browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-chrome-monobook-sauce/295/ [19:20:22] Yippee, build fixed! [19:20:23] Project browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-firefox-monobook-sauce build #311: FIXED in 40 min: https://integration.wikimedia.org/ci/job/browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-firefox-monobook-sauce/311/ [19:38:38] Project browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce build #505: FAILURE in 31 min: https://integration.wikimedia.org/ci/job/browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/505/ [20:15:04] Yippee, build fixed! [20:15:05] Project browsertests-Flow-en.wikipedia.beta.wmflabs.org-windows_8-internet_explorer-sauce build #454: FIXED in 35 min: https://integration.wikimedia.org/ci/job/browsertests-Flow-en.wikipedia.beta.wmflabs.org-windows_8-internet_explorer-sauce/454/ [20:26:52] Project beta-scap-eqiad build #41570: FAILURE in 12 min: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/41570/ [20:42:14] Yippee, build fixed! [20:42:15] Project beta-scap-eqiad build #41572: FIXED in 8 min 12 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/41572/ [20:54:13] 3operations, Deployment-Systems: trebuchet puppet provider broken on systems without upstart - https://phabricator.wikimedia.org/T89461#1037642 (10GWicke) @faidon reported what looks like a missing submodule checkout: ``` restbase1003 restbase[25378]: module.js:340 restbase1003 restbase[25378]: throw err;... [21:06:18] 3Release-Engineering: Add credentials for Echo users to browser test builds in Jenkins - https://phabricator.wikimedia.org/T89497#1037680 (10Cmcmahon) 3NEW a:3hashar [21:11:08] <^demon|busy> greg-g: Actually we've got another frequent offender this week, haven't run it down yet. [21:11:17] <^demon|busy> No such file or directory in /srv/mediawiki/php-1.25wmf16/includes/resourceloader/ResourceLoaderImage.php on line 348 [21:11:37] huh [21:11:46] <^demon|busy> From the logs [21:11:53] yeah [21:12:52] <^demon|busy> Sadly I don't have a stack trace to go on here, could be anything [21:16:08] yeah, seems like something that could be hard to track down [21:17:00] I noticed that go past a couple of times [21:18:38] <^demon|busy> greg-g: Short of throwing it in its own log. [21:18:41] <^demon|busy> (which we could totes do) [21:19:01] <^demon|busy> Actually, let's see [21:19:23] It doesn't make much sense. [21:19:36] the error is from file_get_contents( $tempFilenamePng ) [21:19:47] but $tempFilenamePng = tempnam( wfTempDir(), 'ResourceLoaderImage' ); [21:20:14] tempnam is supposed to create if it doesn't exist... [21:22:19] <^demon|busy> Yeah [21:22:47] could be failing to create, I guess [21:22:57] we don't check for that [21:23:59] php > $ret = file_get_contents( null ); [21:23:59] PHP Warning: file_get_contents(): Filename cannot be empty in php shell code on line 1 [21:24:01] nah, not that [21:24:06] (tried false as well) [21:24:20] <^demon|busy> sync'd a live hack to debug [21:26:05] <^demon|busy> Well that's not very useful. [21:26:06] <^demon|busy> ResourceLoaderImage::rasterize missing temp file, no rsvg: /tmp/ResourceLoaderImageLGQKSa (svg: /tmp/ResourceLoaderImage8nzo4N) [21:26:16] <^demon|busy> temp files don't help me lol [21:26:31] <^demon|busy> Well, a bit. We know we're getting a filename back [21:26:52] and that the filename doesn't exist [21:28:16] <^demon|busy> I see no ResourceLoaderImage* in /tmp at all [21:30:31] ^demon|busy, think I've tracked it down [21:30:46] <^demon|busy> \o/ [21:31:14] SvgHandler::rasterize sends that file off for deletion if stat returns a size of 0 [21:31:47] and logs it in thumbnail.log [21:32:15] 2015-02-13 21:25:42 mw1104 enwiki: Removing bad 0-byte thumbnail "/tmp/ResourceLoaderImageLGQKSa". unlink() succeeded [21:32:15] 2015-02-13 21:25:42 mw1104 enwiki: thumbnail failed on mw1104: error 1 "Unknown option --no-external-files" from "'/usr/bin/'rsvg-convert --no-external-files -w 512 -h 512 -o '/tmp/ResourceLoaderImageLGQKSa' '/tmp/ResourceLoaderImage8nzo4N'" [21:32:25] which is what happened to your file, ^demon|busy [21:32:50] (removeBadFile defined in includes/media/MediaHandler.php) [21:33:06] <^demon|busy> Ahhh [21:33:12] <^demon|busy> So we've got a bad file somewhere? [21:33:40] the rasterize function returns an error in this case, we're just not handling it in ResourceLoaderImage [21:36:38] 3operations, Continuous-Integration: Create a Debian package for NodePool - https://phabricator.wikimedia.org/T89142#1037736 (10Dzahn) p:5Triage>3Normal [21:38:05] <^demon|busy> Reverted my live hacks out [21:41:06] ^demon|busy, you going to prepare a patch or a task? or shall I make a task? [21:41:24] <^demon|busy> I don't have a patch in mind :p [21:42:00] ok, so one of us should make a task [21:47:51] <^demon|busy> clearly [21:50:52] hey gang, is the scap job stuck? https://integration.wikimedia.org/ci/view/Beta/job/beta-scap-eqiad/41578/ [21:51:31] no [21:51:41] marktraceur: !!!! [21:51:51] it wasn't stuck [21:57:12] * ^demon|busy remembers a task about killing that job in favor of something sane [21:58:29] Sorry [21:58:38] It finished this time in a reasonable(ish) time, so [21:59:26] nothing wrong with <5 minutes [22:35:42] ryasmeen: Elena just sent me a link to a google doc with some mobile app regression test descriptions. I think it would be good to use those on mediawiki.org if possible. [22:37:30] otoh, so many of the "test case" pages on mw.o are terrible, we should take a pass and delete them or deprecate them or something. [22:40:14] ^demon|busy, so are you going to, or..? [22:43:37] <^demon|busy> One moment... [22:45:12] chrismcmahon: I agree, I also often get lost when I try to look for something related to that in mediawiki [22:47:10] <^demon|busy> Krenair: T89505 filed [22:49:48] ^demon|busy: $0.02 unsolicited -- the beta-scap-eqiad job is completely sane and the only reasonable way to test scap on a continual basis. If you hate on it, hate on the l10nupdate segment and how it crushes deployment-bastion. [22:52:40] that's actually my opinion as well, I like that it's how we deploy in both beta and prod [22:54:07] can we not just have some way to determine whether we need to run l10nupdate or not? [22:54:18] can we sic ori on the l10nupdate segment maybe? [22:54:18] (I'm guessing this is hard) [22:55:26] <^demon|busy> I hate everything about our l10nupdate crap [22:55:28] We do have a way and it's by running l10nupdate. When there's nothing to update it doesn't take lone. The problem is that updating the l10ncache is stupid expensive [22:55:34] <^demon|busy> I like that "compile to a static APC cache" thing [22:55:43] * take long [22:56:33] Once it decides to update, it stats every freaking l10n file multiple times which is a huge io bruden on the kernel [22:57:58] this is because the data in the cache is serialized php objects with timestamps. An update basically decides "this file has changed" and then compares each and every key in the file to the cache to see if it should be altered or not. It does this because the cache can actually have data that is newer than the files on disk [22:58:19] oi [22:58:29] that's the crazy part. you have to look at each key and decide if the cache or the source file is authoratative [22:59:28] but it is aslo what makes the nightly l10nupdate vs master work (execpt when it's broken because of scap like it has been since December) [23:25:44] !log cherry-picked https://gerrit.wikimedia.org/r/#/c/190231/ to deployment-salt for testing [23:25:47] Logged the message, Master