[03:29:07] PROBLEM - BetaLabs: Low disk space on /var on labmon1001 is CRITICAL: CRITICAL: deployment-prep.deployment-bastion.diskspace._var.byte_avail.value (10.00%) [04:36:41] Yippee, build fixed! [04:36:41] Project browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #95: FIXED in 9 min 28 sec: https://integration.wikimedia.org/ci/job/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/95/ [05:21:00] Yippee, build fixed! [05:21:00] Project browsertests-PageTriage-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #142: FIXED in 47 sec: https://integration.wikimedia.org/ci/job/browsertests-PageTriage-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/142/ [06:27:06] PROBLEM - BetaLabs: Low disk space on /var on labmon1001 is CRITICAL: CRITICAL: deployment-prep.deployment-bastion.diskspace._var.byte_avail.value (10.00%) [06:36:16] RECOVERY - BetaLabs: Low disk space on /var on labmon1001 is OK: OK: All targets OK [07:08:09] Yippee, build fixed! [07:08:09] Project browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-windows_8-internet_explorer-sauce build #198: FIXED in 6 Minuten 11 Sekunden: https://integration.wikimedia.org/ci/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-windows_8-internet_explorer-sauce/198/ [07:13:46] Yippee, build fixed! [07:13:47] Project browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #200: FIXED in 5 Minuten 37 Sekunden: https://integration.wikimedia.org/ci/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/200/ [07:26:03] Yippee, build fixed! [07:26:03] Project browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-windows_7-internet_explorer-9-sauce build #41: FIXED in 7 Minuten 1 Sekunde: https://integration.wikimedia.org/ci/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-windows_7-internet_explorer-9-sauce/41/ [07:27:44] Project browsertests-VisualEditor-test2.wikipedia.org-windows_8-internet_explorer-sauce build #40: ABORTED in 13 min: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-test2.wikipedia.org-windows_8-internet_explorer-sauce/40/ [07:27:45] Project browsertests-Flow-test2.wikipedia.org-linux-chrome-sauce build #186: ABORTED in 11 min: https://integration.wikimedia.org/ci/job/browsertests-Flow-test2.wikipedia.org-linux-chrome-sauce/186/ [07:27:45] Project browsertests-VisualEditor-test2.wikipedia.org-linux-firefox-sauce build #217: ABORTED in 1 min 32 sec: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-test2.wikipedia.org-linux-firefox-sauce/217/ [07:36:39] zeljkof: morning. I have upgraded jenkins and it apparently lost its build queue :D [07:36:48] hashar: morning [07:36:52] :) [07:37:01] was there something important there? [07:38:14] zeljkof: browser tests jobs :D [07:38:15] Yippee, build fixed! [07:38:15] Project browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce build #200: FIXED in 2 min 36 sec: https://integration.wikimedia.org/ci/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/200/ [07:38:27] hashar: they will restart in a few hours anyway [07:38:41] yeah I am not too worried [07:41:09] zeljkof: I was talking with greg yesterday about the browsertests perf issue [07:41:30] apparently running them on sauce and having at most 1 per node solved most issues [07:42:06] hashar: yes, looks like we no longer have a lot of random failures [07:42:13] and I am not sure if anything that needs to be done [07:42:24] or whether we can run multiple sauce jobs on a same instance again [07:42:42] I need to spend some time testing it [07:43:01] but the situation now is good, for now [07:43:09] apparently chris still has some concerns [07:43:24] which concerns? [07:43:28] but the whole stack is confusing me ( selenium / wait / our ruby gems etc) [07:43:34] dont know [07:43:37] network time out [07:43:50] losing the connection with firefox (in case of local browser tests, not the sauce ones) [07:43:51] hm [07:44:07] I don't have that much details :-] [07:44:20] I will talk with him today [07:44:57] if you can find out a way to list out issues ideally with some traces, that would give us a good base to investigate [07:45:31] ok [07:47:24] Timo wrote a puppet patch to use Chromium instead of phantomjs: https://gerrit.wikimedia.org/r/#/c/163791/ ""Implement role::ci::slave::localbrowser (Chromium)"" [07:48:04] I saw that [07:48:13] looks like people are giving up on phantomjs [07:48:39] it is apparently based on Safari/Webkit [07:50:02] and Safari is migrating to Nitro, the engine behind Chromium [07:50:44] or something like that, [07:50:47] heard about that [07:50:55] also not sure about the details [07:53:07] I am not either [07:53:12] nitro is unrelated apparently [07:55:04] Yippee, build fixed! [07:55:05] Project browsertests-UniversalLanguageSelector-commons.wikimedia.beta.wmflabs.org-linux-firefox-sauce build #195: FIXED in 19 min: https://integration.wikimedia.org/ci/job/browsertests-UniversalLanguageSelector-commons.wikimedia.beta.wmflabs.org-linux-firefox-sauce/195/ [08:18:19] 3Wikimedia / 3Continuous integration: Jenkins: The GIT Plugin is broken for submodules ("git-submodule: git reset: not found") - 10https://bugzilla.wikimedia.org/71533#c6 (10Antoine "hashar" Musso) Thank you Timo! I testing out with the job that shown the issue yesterday: https://integration.wikimedia.org/c... [08:21:20] Project browsertests-VisualEditor-test2.wikipedia.org-windows_8-internet_explorer-sauce build #41: STILL FAILING in 17 min: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-test2.wikipedia.org-windows_8-internet_explorer-sauce/41/ [08:22:44] (03CR) 10Hashar: [C: 032] "The bug https://bugzilla.wikimedia.org/show_bug.cgi?id=71533 has been fixed by hacking in the Jenkins git plugin :-)" [integration/zuul-config] - 10https://gerrit.wikimedia.org/r/162635 (owner: 10XZise) [08:22:56] (03Merged) 10jenkins-bot: [FEAT] Add nose34 test for pywikibot and Python 3 [integration/zuul-config] - 10https://gerrit.wikimedia.org/r/162635 (owner: 10XZise) [08:32:17] Project browsertests-Flow-test2.wikipedia.org-linux-chrome-sauce build #187: STILL FAILING in 28 min: https://integration.wikimedia.org/ci/job/browsertests-Flow-test2.wikipedia.org-linux-chrome-sauce/187/ [09:00:02] !sal [09:00:02] https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [09:02:07] 3Wikimedia Labs / 3deployment-prep (beta): deployment-mediawiki02 and mediawiki03 have puppet disabled - 10https://bugzilla.wikimedia.org/71410#c1 (10Antoine "hashar" Musso) 5NEW>3RESO/FIX Puppet has been reenabled somehow. [09:23:07] Project browsertests-VisualEditor-test2.wikipedia.org-linux-firefox-sauce build #218: SUCCESS in 1 hr 1 min: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-test2.wikipedia.org-linux-firefox-sauce/218/ [09:48:03] 3Wikimedia / 3Continuous integration: Jenkins: migrate Mediawiki regression jobs to Zuul cloner - 10https://bugzilla.wikimedia.org/71549 (10Antoine "hashar" Musso) 3NEW p:3Unprio s:3minor a:3Antoine "hashar" Musso The mediawiki-core-regression* jobs are run on post merge on a per branch basis. They n... [09:48:16] 3Wikimedia / 3Continuous integration: Jenkins: migrate Mediawiki regression jobs to Zuul cloner - 10https://bugzilla.wikimedia.org/71549 (10Antoine "hashar" Musso) p:5Unprio>3Highes [10:32:11] zeljkof: https://rubygems.org/gems/mediawiki_api-wikidata [10:33:14] zeljkof: https://github.com/wmde/WikidataApiGem [10:42:52] zeljkof: https://github.com/wmde/WikidataApiGem/blob/master/mediawiki_api-wikidata.gemspec [10:44:50] Tobi_WMDE_SWE: http://bundler.io/gemfile.html [10:50:24] Tobi_WMDE_SWE: https://gerrit.wikimedia.org/r/#/c/163857/ [10:55:42] (03PS4) 10Tobias Gritschacher: Move wikidata-performance browsertests job to WMF Jenkins [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/163129 [11:21:52] hashar: a quick question [11:23:30] zeljkof: back from lunch/nap :] [11:24:08] can a jjb shell script be combined from several smaller ones? [11:24:19] nop [11:24:28] so the result is just one script? [11:24:35] well if you do: [11:24:39] no is not acceptable. :) [11:24:44] - shell: "VAR=foobar" [11:24:49] - shell: "echo $VAR" [11:24:59] the second is run in a different shell and $VAR is undefined there [11:25:02] yes [11:25:09] Tobi_WMDE_SWE and I have just tested that :) [11:25:30] is there a way for us to load bunch of env variables when a shell starts? [11:25:45] for CI purposes, I moved a lot of shell scripts to integration/jenkins.git which is cloned under /srv/deployment/integration/slave-scripts [11:26:04] and parameters passed to jobs are exported to the environement [11:26:13] so you could add the job a VAR parameter defaulting to 'foobar' [11:26:23] and thus - shell: "echo $VAR" would print 'foobar' [11:26:46] that being said, JJB recently received a new feature which let you include content from another file [11:27:19] and something like this? http://stackoverflow.com/a/19331521/17469 [11:27:21] http://ci.openstack.org/jenkins-job-builder/definition.html#module-jenkins_jobs.local_yaml [11:27:28] so you can: [11:27:29] - shell: [11:27:29] !include-raw include-raw001-hello-world.sh [11:27:43] and maybe you can invoke !include-raw several times [11:28:15] yeah you could use 'source' [11:28:28] I think I used that in one of the job [11:28:40] a shell step write some env variable in $WORKSPACE/env.sh [11:28:46] which is then loaded in other -shell part [11:28:57] are you refactoring the cucumber macro ? :-D [11:34:11] (03PS1) 10Hashar: mediawiki-core-regression* jobs now use Zuul cloner [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164309 (https://bugzilla.wikimedia.org/71549) [11:40:08] (03PS2) 10Hashar: mediawiki-core-regression* jobs now use Zuul cloner [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164309 (https://bugzilla.wikimedia.org/71549) [11:57:44] !log Migrated all mediawiki-core-regression* jobs to Zuul cloner [11:57:48] Logged the message, Master [11:58:00] !log Migrated all mediawiki-core-regression* jobs to Zuul cloner {{bug|71549}} [11:58:03] Logged the message, Master [12:06:03] (03CR) 10Hashar: [C: 032] "I have updated all jobs and cleared out the workspaces on all production and labs slaves." [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164309 (https://bugzilla.wikimedia.org/71549) (owner: 10Hashar) [12:06:45] 3Wikimedia / 3Continuous integration: Jenkins: migrate Mediawiki regression jobs to Zuul cloner - 10https://bugzilla.wikimedia.org/71549#c2 (10Antoine "hashar" Musso) 5PATC>3RESO/FIX I have updated all jobs and cleared out the workspaces on all production and labs slaves. One less job to migrate to use... [12:09:07] (03Merged) 10jenkins-bot: mediawiki-core-regression* jobs now use Zuul cloner [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164309 (https://bugzilla.wikimedia.org/71549) (owner: 10Hashar) [12:42:27] Project browsertests-WikidataTest-wikidata.beta.wmflabs.org-linux-firefox-sauce build #1: FAILURE in 0.51 sec: https://integration.wikimedia.org/ci/job/browsertests-WikidataTest-wikidata.beta.wmflabs.org-linux-firefox-sauce/1/ [12:45:01] that is a fast failure Tobi_WMDE_SWE ^^^ :D [12:55:07] +OK HbNHV0zPAyu/JsIto/qz84O/ [12:57:52] (03PS1) 10Hashar: Migrate mediawiki-core-code-coverage to Zuul cloner [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164313 [13:02:52] (03CR) 10Hashar: [C: 032] "That is part of supporting mediawiki/vendor by switching jobs to use Zuul cloner." [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164313 (owner: 10Hashar) [13:06:12] (03Merged) 10jenkins-bot: Migrate mediawiki-core-code-coverage to Zuul cloner [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164313 (owner: 10Hashar) [13:10:37] (03PS1) 10Hashar: Move search* jobs from misc.yaml to search.yaml [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164315 [13:13:56] (03PS1) 10Hashar: Jobs for search/extra [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164316 [13:14:48] (03PS2) 10Hashar: Jobs for search/extra [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164316 [13:23:45] hashar: just testing various things.. ;) [13:23:56] but got distraced, need to do other stuff [13:30:01] (03CR) 10Hashar: [C: 032] "noop change :)" [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164315 (owner: 10Hashar) [13:32:11] (03PS1) 10Hashar: Jobs for search/extra [integration/zuul-config] - 10https://gerrit.wikimedia.org/r/164317 [13:33:13] (03CR) 10Hashar: [C: 032] Jobs for search/extra [integration/zuul-config] - 10https://gerrit.wikimedia.org/r/164317 (owner: 10Hashar) [13:33:21] (03Merged) 10jenkins-bot: Jobs for search/extra [integration/zuul-config] - 10https://gerrit.wikimedia.org/r/164317 (owner: 10Hashar) [13:33:55] (03Merged) 10jenkins-bot: Move search* jobs from misc.yaml to search.yaml [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164315 (owner: 10Hashar) [14:17:42] (03PS1) 10Tobias Gritschacher: Make repository host parameterizable [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164332 [14:19:48] hashar: zeljkof: does https://gerrit.wikimedia.org/r/#/c/164332/ make sense to you? [14:20:13] that would bring us one step closer to use standard templates for wikidata browsertest jobs [14:20:24] as we are hosting them on github.. [14:29:39] Tobi_WMDE_SWE: looking [14:30:11] scaaaaary [14:31:49] (03CR) 10Zfilipin: [C: 04-1] Make repository host parameterizable (031 comment) [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164332 (owner: 10Tobias Gritschacher) [14:31:56] (03CR) 10Hashar: [C: 04-1] "I would make repository_host to default to Wikimedia Gerrit in the browser test default. Then for jobs that uses github override that var" [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164332 (owner: 10Tobias Gritschacher) [14:32:05] Tobi_WMDE_SWE: gerrit could be made the default I think [14:32:05] Tobi_WMDE_SWE: replied, I think there is a simpler way [14:32:18] hashar, Tobi_WMDE_SWE: exactly my thoughts [14:32:54] or get rid of github :D [14:32:57] hashar: how can you specify a default for variables [14:34:55] Tobi_WMDE_SWE: you can probably do it in the job-templates [14:35:27] hashar: I've looked at the jjb documentation and was not able to find out how to do that. [14:35:29] it might even work in the default defined in job-templates-browsertests.yaml line 70 [14:35:35] would prefer having a default as well [14:35:44] then we would not have to change the other jobs [14:39:16] 3Wikimedia / 3Continuous integration: Document CI doc publishing process - 10https://bugzilla.wikimedia.org/69975#c2 (10Antoine "hashar" Musso) 5NEW>3RESO/FIX I have amended a bit the document about the security rules. I am assuming it is good enough now. [14:39:46] Tobi_WMDE_SWE: yeah that is the idea [14:40:20] hashar: yeah, but still no idea to define a default for a variable in jjb [14:44:44] Tobi_WMDE_SWE: I actually coded a feature to pass variables defined in 'defaults' down to job templates [14:45:51] Tobi_WMDE_SWE: http://paste.openstack.org/show/117785/ [14:46:23] Tobi_WMDE_SWE: the documentation I wrote ended up at http://ci.openstack.org/jenkins-job-builder/definition.html#defaults [14:46:36] in the defaults, you can define a variable [14:46:54] the 'global' defaults is a special one which is used by job-templates when none is specified [14:47:11] hashar: ah, ok, I just figured that out. great.. will try [14:47:14] in my paste, I defined a samovar: 'my value' which is passed down to the builder [14:47:36] templates and how variables are passed is a bit scary. That gave me headaches more than once [14:47:59] a potential useful thing is to create a new directory write some very simple yaml definition in there [14:48:13] then test the XML generation with: jenkins-jobs test whateverdir/ [14:48:36] that will dump to stdout the XML and it is way faster than regenerating all the jobs and doing a diff against a previous backup [14:49:25] to use that feature of JJB you will need commit 98b69476eaca38647f88a23d266cc677213ba1fd merged in Aug 22. It is up to date in integration/jenkins-job-builder.git [14:56:32] (03PS2) 10Tobias Gritschacher: Make repository host parameterizable [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164332 [14:57:02] (03CR) 10jenkins-bot: [V: 04-1] Make repository host parameterizable [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164332 (owner: 10Tobias Gritschacher) [14:59:01] hashar: hm.. seems the default is not working.. https://gerrit.wikimedia.org/r/#/c/164332/ [15:01:31] hashar: or do I need to put - defaults: also in browsertests.yaml [15:02:40] Tobi_WMDE_SWE: the default 'browsertests' is applied on the job templates in job-templates-browsertests.yaml [15:02:56] we can probably move them up to project :D [15:03:38] still confused.. [15:14:51] (03PS1) 10Hashar: mwcore-docgen: let us override base destination [integration/jenkins] - 10https://gerrit.wikimedia.org/r/164343 [15:14:54] hashar: need to look a bit more into that. hve to go now though.. maybe I can further work on that on monday [15:15:02] (03CR) 10Hashar: [C: 032] mwcore-docgen: let us override base destination [integration/jenkins] - 10https://gerrit.wikimedia.org/r/164343 (owner: 10Hashar) [15:15:13] tomorrow there is a holiday in germany. me was told.. :) [15:15:31] (03PS2) 10Hashar: mwcore-docgen: let us override base destination [integration/jenkins] - 10https://gerrit.wikimedia.org/r/164343 [15:15:53] Tobi_WMDE_SWE: sure poke me on monday :) [15:16:01] Tobi_WMDE_SWE: we can even pair together over hangout/skype [15:16:36] hashar: ah, we have the multimedia team here in the office next week, I'll see if I can sneak out. :) [15:17:50] (03CR) 10Hashar: [C: 032] mwcore-docgen: let us override base destination [integration/jenkins] - 10https://gerrit.wikimedia.org/r/164343 (owner: 10Hashar) [15:17:52] (03Merged) 10jenkins-bot: mwcore-docgen: let us override base destination [integration/jenkins] - 10https://gerrit.wikimedia.org/r/164343 (owner: 10Hashar) [15:19:35] manybubbles: I crafted some job for search/extra :-] [15:19:48] doesn't publish anything though :-/ [15:34:19] (03PS1) 10Hashar: mwcore-docgen: bash typo [integration/jenkins] - 10https://gerrit.wikimedia.org/r/164345 [15:34:31] (03CR) 10Hashar: [C: 032] mwcore-docgen: bash typo [integration/jenkins] - 10https://gerrit.wikimedia.org/r/164345 (owner: 10Hashar) [15:34:32] (03Merged) 10jenkins-bot: mwcore-docgen: bash typo [integration/jenkins] - 10https://gerrit.wikimedia.org/r/164345 (owner: 10Hashar) [15:39:17] (03PS1) 10Hashar: (WIP) migrate mw doxygen to zuul-cloner and Trusty (WIP) [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164354 [15:40:08] (03PS2) 10Hashar: (WIP) migrate mw doxygen to zuul-cloner and Trusty (WIP) [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164354 (https://bugzilla.wikimedia.org/46771) [15:41:46] 3Wikimedia / 3Continuous integration: Update doxygen from 1.7.x to 1.8.x on gallium - 10https://bugzilla.wikimedia.org/46771#c17 (10Antoine "hashar" Musso) 5PATC>3ASSI a:3Antoine "hashar" Musso This can be run on a Trusty labs instance which have doxygen 1.8.x. We also have the infrastructure to publi... [15:43:10] I am off for today [15:43:14] see you tomorro [15:43:15] w [16:13:45] 3Wikimedia / 3Continuous integration: Update doxygen from 1.7.x to 1.8.x on gallium - 10https://bugzilla.wikimedia.org/46771#c18 (10Antoine "hashar" Musso) WIP result: https://doc.wikimedia.org/hashar/mediawiki-core/master/php/html/ Compare with https://doc.wikimedia.org/mediawiki-core/master/php/html/ [16:14:45] (03CR) 10Hashar: "WIP result: https://doc.wikimedia.org/hashar/mediawiki-core/master/php/html/" [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164354 (https://bugzilla.wikimedia.org/46771) (owner: 10Hashar) [16:21:24] zeljkof: it's definitely a bug in Flow that caused the test failure we saw, I'm about to report it [16:32:59] chrismcmahon: great :)đ [16:34:04] zeljkof: yep, https://bugzilla.wikimedia.org/show_bug.cgi?id=71558 Today if you "hide" a topic in Flow, you will never ever see it again. :-) [16:35:50] :) [17:07:15] chrismcmahon: fyi, labs and thus beta cluster seem to be down [17:07:16] they're looking into it [17:07:16] mark and coren [17:07:16] yep, I noticed just now [17:23:46] chrismcmahon: wee, back [17:26:50] Reedy: btw, have you made the new branches yet [17:26:51] ? [17:28:44] * greg-g looks in gerrit :) [17:29:57] nope [17:30:59] nope [17:31:06] just updating/tidying up my working copy [17:31:08] then going to [17:32:27] * greg-g nods [17:32:53] someone sent a "I don't want this to go out today!" email to me, and I just said "revert quickly" [18:35:53] greg-g: are you changing swat times ? [18:36:54] matanya: not today, not next week, maybe after that, I need to reasses the feedback. I've been sick all week so I'm really slow right now :/ [18:37:06] but, "yes" [18:37:09] probably [18:37:11] maybe [18:37:14] ish [18:37:16] ;) [18:37:17] oh, feel well! [18:37:36] thanks :) [18:38:00] 3Wikimedia / 3Continuous integration: [project] trigger browser tests from Gerrit (tracking) - 10https://bugzilla.wikimedia.org/53697#c7 (10Matthew Flaschen) (In reply to Antoine "hashar" Musso from comment #6) > This is no more a top priority. We have most browsertests run twice per day > instead. > > We... [18:52:37] Project browsertests-Core-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #206: FAILURE in 12 min: https://integration.wikimedia.org/ci/job/browsertests-Core-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/206/ [19:42:05] !log Updated scap to include eff0d01 Fix format specifier for error message [19:42:09] Logged the message, Master [19:57:02] Project browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #96: FAILURE in 10 min: https://integration.wikimedia.org/ci/job/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/96/ [20:05:07] Project beta-scap-eqiad build #23875: FAILURE in 1 min 16 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/23875/ [20:14:58] Yippee, build fixed! [20:14:59] Project beta-scap-eqiad build #23876: FIXED in 1 min 3 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/23876/ [20:15:00] i dunno if you all deal with mw/phpunit much, but looking for ideas on how to put the database into an expected state before particular tests [20:15:31] I tried poking around in core for ideas, but i just see things like if ( !Title::newFromText( 'Help:UTPage' )->exists() ) { $this->markTestSkipped( '...' ); } [20:15:39] so not sure how core gets the db into expected states [20:16:00] wiki gnomes [20:16:23] ebernhardson: mock the db [20:17:00] chrismcmahon: i'm trying to do api level integration tests, so that seems like a bit of a barrier, would like it to actually do a full integration test [20:17:47] ebernhardson: in that case use the API. what are you actually trying to accomplish in the test? [20:18:19] chrismcmahon: well, this is just the first since we dont even test our api yet :) In this case a board should exist with a single topic, and i will issue an api request to lock the topic, then check on the state of that topic after the api call [20:18:36] (since i'm adjusting our lock topic stuff right now, gotta start somewherE) [20:19:09] i could issue the create topic api request in stream i guess, but we don't yet have an api for creating boards...but i guess i can create it manually. hmm [20:19:41] $wgFlowOccupyNamespaces = array( NS_USER_TALK ) then you know it's a virgin board [20:19:46] ebernhardson: OK, so for example in many of the browser tests we put a target page into an expected state using the "create()" API call, which conveniently clobbers the contents of any existing page [20:20:11] sorry, that should have been preceded "You can create a random new user, and then if..." [20:20:35] chrismcmahon: hmm, yea that should be workable. thanks! [20:21:06] ebernhardson: I'm not sure what the API exposes for Flow stuff, but I'd like to know more [20:21:14] we could also add a dedicated NS_QA_FLOW_BOARDS and create boards in that [20:21:44] chrismcmahon: just open the Net browser tools panel while interacting with a Flow board. [20:21:46] chrismcmahon: at a base level, the api for flow exposes everything that can be done. Both the API classes and the Action classes(for regular pages) are thin little shims that both talk to the same flow [20:22:48] all the Action classes really do is run the api request and pass the result into templating [20:23:01] oh cool, I was eyeing a couple of action classes just recently when rejiggering tests, they seem to be the result of tags [20:23:02] chrismcmahon: also, https://www.mediawiki.org/wiki/Special:ApiSandbox#action=flow and click the submodule dropdown, that gives you a hint [20:24:34] chrismcmahon: yea, as part of our js/nojs compatability, the api urls just take the parameters we have in anchors/forms and rewrite them to api requests(mostly just prefixing that api expects, and a little extra magic for specific forms that get client side validation) [20:24:48] (i think thats what you meant), so the api requests are basically sourced from the hrefs [20:25:12] yep, I liked it, it was very clear what was happening [20:25:22] ebernhardson: I don't see a view-history submodule in there, do you use the regular action=query to get Flow history? [20:26:34] spagewmf ebernhardson while I have you on the line, I am guessing that https://bugzilla.wikimedia.org/show_bug.cgi?id=71558 is actually desired behavior after reading https://gerrit.wikimedia.org/r/#/c/164277/ [20:27:14] chrismcmahon: yea thats intended, thats what i was talking about yesterday when i said i forgot to check the related tests because we just updated how hide works [20:27:23] i should have been more clear about what exactly changed [20:27:55] chrismcmahon: yup. We have to rethink the tests. "And only I see an undo button"... and another user no longer sees the moderated topic [20:28:01] etc. [20:28:05] OK. So a user with the power to hide topics gets one change to "Undo", and then the Topic goes away forever then, yes? [20:28:12] chance, even [20:28:15] its then only found in history and contributions [20:28:34] and the related page in the Topic namespace is still accesible by anyone that has the flow-hide right(everyone currently) [20:28:41] via that history/contributinos [20:28:46] OK [20:29:22] oh hey, Danny replied, I'd missed that [20:29:23] yup, so and so "When anyone goes to see the hidden topic it appears with a reason xyz..." [20:29:31] spagewmf, quick qn. ... reg your comment on https://gerrit.wikimedia.org/r/#/c/161161/ about +2ing after the branch is cut, can you clarify? I didn't understand. parsoid deploys are independent of core deploys. [20:29:52] and apologies for interrupting your conversation here. [20:31:14] subbu: probably just didn't realize you have your own deploy schedule :) At least in flow we usually push many things just after deploy branches are cut so it gets a week on beta and our tests instances before going out [20:31:17] subbu: no worries, hi! I just figured any change to Parsoid could wait until after the Thursday deploy to stage 0 wikis. If that doesn't apply then merge whenever [20:31:39] ah, ok. thanks. [20:32:06] subbu: I assume merged Parsoid changes flow (ha ha) to beta labs within the hour? [20:32:32] yes, the merge is deployed to beta by a post-deploy jenkins task right away. [20:32:47] courtesy hashar [20:52:40] spagewmf ebernhardson I think this dtrt: https://gerrit.wikimedia.org/r/#/c/164422 for testing hidden/moderated Topics [21:08:09] Yippee, build fixed! [21:08:09] Project browsertests-VisualEditor-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #310: FIXED in 1 hr 9 min: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/310/ [21:22:23] Project browsertests-PdfHandler-test2.wikipedia.org-linux-firefox-sauce build #115: FAILURE in 1 min 24 sec: https://integration.wikimedia.org/ci/job/browsertests-PdfHandler-test2.wikipedia.org-linux-firefox-sauce/115/ [21:38:04] chrismcmahon: I'm reviewing I notice that moderation.feature and moderation_anon.feature don't run in CI (and are broken). [21:39:17] spagewmf: yeah, I had to completely re-do https://gerrit.wikimedia.org/r/#/c/163993/ it was hopeless [21:40:01] spagewmf: header.feature is also busted [21:40:58] chrismcmahon: uh oh. how do you want to divide up the work? What *aren't* you working on :) [21:43:29] spagewmf: I was going to skip headings and take lock_unlock_topics.feature next. but I'm on vacation all next week and I have a 90 minute meeting starting in 15 [21:43:43] so whatever I can get done tomorrow is it for a while [21:44:11] OK, I'll review your stuff and investigate/fix headings. [21:44:54] spagewmf: what I actually set out to do this week was to replace all the old "should" RSpec syntax with modern "expect" syntax, but holy moly there is some wacky code in this suite [21:47:07] chrismcmahon: as you fix things, can you have a draft message to e2 (Flow team) about improvements? "Teach a team to fix and it can QA itself", and I promise to update Writing tests wiki page [21:48:18] spagewmf: yep, I've been doing that a bit in code review and bugzilla with you and ebernhardson and Matt. [21:48:37] but adding in the mail list is a good idea also [21:48:47] I mentioned the expect() switch, I dunno what other anti-patterns and misteaks you're seeing [21:50:10] spagewmf: Matt and I talked about using "==" for string equality where he had used "===" , which is weird in Ruby, for one thing [21:51:37] spagewmf: also, I'll be in SF in person Oct 21/22/23, it would be super to do some test programming in person for Flow stuff [21:53:33] but yeah, I'll send a summary of findings to the e2 list tomorrow