[00:18:17] Yippee, build fixed! [00:18:18] Project browsertests-VisualEditor-test2.wikipedia.org-windows_8-internet_explorer-sauce build #42: FIXED in 1 hr 16 min: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-test2.wikipedia.org-windows_8-internet_explorer-sauce/42/ [00:18:30] Ha. [00:18:37] That's IE10 blacklist removal going into effect. :-) [00:19:07] James_F: high five [00:19:24] chrismcmahon: Lovely to see the browser tests confirming our local testing. :-) [00:19:34] indeed! [00:20:02] lovely to have a failing build in place to show it, also [00:24:31] Project browsertests-VisualEditor-test2.wikipedia.org-linux-firefox-sauce build #219: FAILURE in 1 hr 9 min: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-test2.wikipedia.org-linux-firefox-sauce/219/ [00:25:48] Yippee, build fixed! [00:25:48] Project browsertests-Math-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #145: FIXED in 1 min 16 sec: https://integration.wikimedia.org/ci/job/browsertests-Math-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/145/ [00:27:32] that was a weird failure, Selenium_user got logged out halfway through. I thought I killed the last explicit logout months ago, I wonder if someone has written a new one. [03:05:02] Project browsertests-TwnMainPage-sandbox.translatewiki.net-linux-firefox-sauce build #163: FAILURE in 1 min 1 sec: https://integration.wikimedia.org/ci/job/browsertests-TwnMainPage-sandbox.translatewiki.net-linux-firefox-sauce/163/ [03:17:48] (03PS5) 10Krinkle: Remove unused distinction between phpcs-strict and phpcs-lenient [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/161757 (https://bugzilla.wikimedia.org/48420) (owner: 10Jforrester) [03:19:31] (03CR) 10Krinkle: "I don't think anyone of the end-users affected by this (incl. Siebrand) is interested in this distinction. When "cleaning up" a file and "" [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/161757 (https://bugzilla.wikimedia.org/48420) (owner: 10Jforrester) [03:19:54] (03PS7) 10Krinkle: Significantly simplify phpcs job configuration [integration/zuul-config] - 10https://gerrit.wikimedia.org/r/161763 (https://bugzilla.wikimedia.org/48420) (owner: 10Jforrester) [03:44:47] Project beta-scap-eqiad build #23923: FAILURE in 55 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/23923/ [03:49:20] PROBLEM - BetaLabs: Low disk space on /var on labmon1001 is CRITICAL: CRITICAL: deployment-prep.deployment-bastion.diskspace._var.byte_avail.value (11.11%) [03:54:44] Yippee, build fixed! [03:54:45] Project beta-scap-eqiad build #23924: FIXED in 49 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/23924/ [03:56:47] Yippee, build fixed! [03:56:48] Project browsertests-Core-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #207: FIXED in 13 min: https://integration.wikimedia.org/ci/job/browsertests-Core-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/207/ [04:16:53] Project browsertests-UniversalLanguageSelector-sandbox.translatewiki.net-linux-firefox-sauce build #174: FAILURE in 1 min 2 sec: https://integration.wikimedia.org/ci/job/browsertests-UniversalLanguageSelector-sandbox.translatewiki.net-linux-firefox-sauce/174/ [05:03:13] Reedy: around? if so can you approve my oauth consumer for phabricator? (key = 211867c109f5b97b392082965a1abd4b ) [05:21:12] Yippee, build fixed! [05:21:12] Project browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce build #238: FIXED in 33 min: https://integration.wikimedia.org/ci/job/browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/238/ [05:33:40] Yippee, build fixed! [05:33:40] Project browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce build #83: FIXED in 9 min 7 sec: https://integration.wikimedia.org/ci/job/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/83/ [06:36:07] RECOVERY - BetaLabs: Low disk space on /var on labmon1001 is OK: OK: All targets OK [07:30:38] good morning [07:32:30] !git [07:32:36] !sal [07:32:36] https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [08:24:38] !log deployment-bastion clearing up /var/log/account a bit {{bug|69604}}. Puppet patch pending :] [08:24:44] Logged the message, Master [08:38:14] 3Wikimedia Labs / 3deployment-prep (beta): deployment-rsync01 20GB hard drive is too small - 10https://bugzilla.wikimedia.org/71431#c7 (10Antoine "hashar" Musso) Thanks Bryan for the detailed explanation :-) [09:07:50] Yippee, build fixed! [09:07:51] Project browsertests-VisualEditor-test2.wikipedia.org-linux-firefox-sauce build #220: FIXED in 1 hr 8 min: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-test2.wikipedia.org-linux-firefox-sauce/220/ [09:28:41] Project browsertests-UniversalLanguageSelector-commons.wikimedia.beta.wmflabs.org-linux-firefox-sauce build #197: FAILURE in 20 min: https://integration.wikimedia.org/ci/job/browsertests-UniversalLanguageSelector-commons.wikimedia.beta.wmflabs.org-linux-firefox-sauce/197/ [09:39:03] 3Wikimedia / 3Quality Assurance: mediawiki_selenium always use the same default xvfb display 99 - 10https://bugzilla.wikimedia.org/71602 (10Antoine "hashar" Musso) 3NEW p:3Unprio s:3normal a:3None Our firefox browser tests running on local instances kept complaining of losing connection to the firefo... [09:41:57] argh [11:53:18] twentyafterfour: Done [14:01:33] !log rebuilding beta's simplewiki cirrus index [14:01:38] Logged the message, Master [18:06:39] (03PS1) 10BryanDavis: Add jobs for iegreview [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164597 [18:10:33] 3Wikimedia / 3Continuous integration: Add Jenkins jobs for iegreview application - 10https://bugzilla.wikimedia.org/71617 (10Bryan Davis) 3NEW p:3Unprio s:3normal a:3Bryan Davis Setup the new wikimedia/iegreview application to run Jenkins jobs via Zuul triggers. This app should have the same jobs as... [18:11:56] (03PS2) 10BryanDavis: Add jobs for iegreview [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164597 (https://bugzilla.wikimedia.org/71617) [18:23:56] (03CR) 10BryanDavis: "Jobs created via:" [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164597 (https://bugzilla.wikimedia.org/71617) (owner: 10BryanDavis) [19:09:29] (03CR) 10Hashar: [C: 032] ":-)" [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164597 (https://bugzilla.wikimedia.org/71617) (owner: 10BryanDavis) [19:09:45] (03CR) 10Hashar: "Sorry forgot: that needs Zuul trigger now :-)" [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164597 (https://bugzilla.wikimedia.org/71617) (owner: 10BryanDavis) [19:12:37] (03Merged) 10jenkins-bot: Add jobs for iegreview [integration/jenkins-job-builder-config] - 10https://gerrit.wikimedia.org/r/164597 (https://bugzilla.wikimedia.org/71617) (owner: 10BryanDavis) [19:15:47] (03PS1) 10BryanDavis: triggers for wikimedia/iegreview [integration/zuul-config] - 10https://gerrit.wikimedia.org/r/164627 (https://bugzilla.wikimedia.org/71617) [19:16:22] hashar: ^ I still never learned how to install the zuul hooks [19:16:37] bd808|LUNCH: finish your lunch and we can talk about it :] [19:26:43] Yippee, build fixed! [19:26:44] Project browsertests-UniversalLanguageSelector-sandbox.translatewiki.net-linux-firefox-sauce build #175: FIXED in 1 min 56 sec: https://integration.wikimedia.org/ci/job/browsertests-UniversalLanguageSelector-sandbox.translatewiki.net-linux-firefox-sauce/175/ [19:27:55] PROBLEM - zuul_service_running on gallium is CRITICAL: PROCS CRITICAL: 0 processes with regex args ^/usr/bin/python /usr/local/bin/zuul-server [19:28:03] PROBLEM - zuul_gearman_service on gallium is CRITICAL: Connection refused [19:30:47] ^^^ me [19:35:54] YuviPanda: the zuul alarms above should be sent to #wikimedia-operations as well I believe [19:36:19] since zuul related folks have less presence than ops folks:D [19:37:03] hashar: hmm, I'm not fully sure how to do that :) [19:37:35] YuviPanda: I though you changed it somehow :] [19:37:46] I did, but I'm not sure how to make it report to both places [19:38:06] actually, I didn't change it. it was all mutante [19:42:03] YuviPanda: file is ./modules/icinga/files/contactgroups.cfg right ? [19:42:35] hashar: yeah, and contacts.cfg. and the ircecho is specified elsewhere [19:42:36] there is a member named 'irc' [19:42:42] I guess that sends to -ops [19:44:42] ah [19:44:47] that's probably what's happening [19:46:56] YuviPanda: puppet patch on its way :] https://gerrit.wikimedia.org/r/164635 [19:47:18] hashar: yay [19:47:23] I still can't merge anything tho [19:47:41] you can still do review though :] [19:47:55] I have +2 on mediawiki/core and I don't think I used it this year [19:48:19] or maybe once to help volunteers that already +1 some change heavily [19:51:51] hashar: i'm sure i could find some changes to tests that could use your attention! :> [19:53:05] hashar: heh :) +1'd [19:54:55] MatmaRex: sadly I am not working much on mw/core anymore [19:55:29] MatmaRex: I couldn't reasonably follow up with all the mw reviews while having to deal with CI / browsertests / beta and such [19:57:51] hashar: ping [19:57:53] hashar: phpcs, have a minute? [20:00:06] Yippee, build fixed! [20:00:07] Project browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #98: FIXED in 10 min: https://integration.wikimedia.org/ci/job/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/98/ [20:01:29] hashar: 1) Wanna figure out situation with phpcs, 2) How/are we still using gearman? 3) Sync up about our quarterly goals in CI and the new upcoming hire (PM) [20:07:54] Krinkle: was busy with some non-work python sorry :D [20:08:14] 2) yeah we are using gearman since that is how Zuul interacts with Jenkins [20:09:22] 1) phpcs is enforced on some repositories when their developers think it is a good idea to have. I think a good chunk of mediawiki/core is more or less passing now. Beside that I don't have much ideas / details. [20:10:51] for CI goals, Zuul cloner and testing multiple repositories together is one. A good part of it is done now. [20:11:00] next would be isolating jobs [20:23:14] hashar: 1) lenient/strict, I want to remove it and just use strict (like the default does) [20:23:38] hashar: 2) But Jenkins has the slave nodes with labels, and the jobs have those labels in them as well. Where/how does gearman come in? [20:23:56] RECOVERY - zuul_service_running on gallium is OK: PROCS OK: 2 processes with regex args ^/usr/bin/python /usr/local/bin/zuul-server [20:24:06] RECOVERY - zuul_gearman_service on gallium is OK: TCP OK - 0.000 second response time on port 4730 [20:33:45] Krinkle: for phpcs, as I said on the review the idea is to let people fix the errors first and make that voting [20:33:50] Krinkle: then they can work on the warnings [20:33:54] hashar: Why? [20:34:01] a two step process that worked well on other repositories [20:34:01] hashar: Who asked for that? Who is actually doing that? I don't believe it [20:34:09] I don't know of a single repo that did it that way [20:34:28] so at a point you end up with only the strict job [20:34:49] We dont have lenient jshint, jscs, phpunit, qunit, etc. [20:36:10] pywikibot is doing the same separation for python linting and docstring linting [20:36:44] I guess that separation applies for existing code bases that have a huge number of issues being reporting and which are not easily solvable in a short time [20:37:52] for Jenkins/gearman, Jenkins does not trigger jobs at all. The Gearman plugin hijack the Jenkins internal system and register the jobs with the Gearman servers. That is then Zuul that decides which Gearman function to run, which in turn trigger a job jin jenkins [20:38:25] the Jenkins labels are understood by the Gearman plugin which from the job + labels craft some Gearman functions [20:39:26] some doc is at http://ci.openstack.org/zuul/launchers.html#zuul-gearman-protocol [20:40:13] a job "myjob" being tied to UbuntuTrusty && ContintLabsSlaves would cause three functions to be registered: [20:40:15] build:myjob [20:40:19] build:myjob:UbuntuTrusty [20:40:25] build:myjob:ContintLabsSlaves [20:41:30] all those three Gearman functions would end up triggering 'my job' which will be run by Jenkins on slaves matching UbuntuTrusty && ContintLabsSlaves [20:41:51] in our context, Zuul only use build:my job [20:43:29] hashar: Should I try to follow the instructions on wm.o to deploy https://gerrit.wikimedia.org/r/#/c/164627/ or just wait for you to have time to do it? [20:45:02] bd808: {{BE BOLD}} :-] [20:45:08] I am here for support! [20:45:32] (03CR) 10Hashar: [C: 031] triggers for wikimedia/iegreview [integration/zuul-config] - 10https://gerrit.wikimedia.org/r/164627 (https://bugzilla.wikimedia.org/71617) (owner: 10BryanDavis) [20:45:37] bd808: we can hangout it if you want. [20:47:36] The wiki page makes it sound easy... [20:49:22] I just submit, pull on gallium and reload the zuul service? [20:49:26] Project browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce build #84: FAILURE in 9 min 31 sec: https://integration.wikimedia.org/ci/job/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/84/ [20:49:37] bd808: yes [20:49:40] bd808: as the zuul user [20:50:03] then I realize you might not have sudo rights :-( [20:50:17] zuul@gallium:~$ [20:50:28] apparently I do :) [20:50:48] that is convenient [20:50:57] so yeah pull reload :-] [20:51:21] that is a little too manual though [20:51:31] (03CR) 10BryanDavis: [C: 032] "Trying my first zuul deploy" [integration/zuul-config] - 10https://gerrit.wikimedia.org/r/164627 (https://bugzilla.wikimedia.org/71617) (owner: 10BryanDavis) [20:51:32] in theory we could use a jenkins job to do it [20:51:40] (03Merged) 10jenkins-bot: triggers for wikimedia/iegreview [integration/zuul-config] - 10https://gerrit.wikimedia.org/r/164627 (https://bugzilla.wikimedia.org/71617) (owner: 10BryanDavis) [20:51:44] you can tail /var/log/zuul/zuul.log [20:51:58] on the status page at https://integration.wikimedia.org/zuul/ [20:52:11] a red warning box might show up briefly [20:52:46] Project browsertests-CirrusSearch-test2.wikipedia.org-linux-firefox-sauce build #176: FAILURE in 2 min 9 sec: https://integration.wikimedia.org/ci/job/browsertests-CirrusSearch-test2.wikipedia.org-linux-firefox-sauce/176/ [20:53:24] looks like it worked... [20:53:51] w00t [20:54:01] jobs triggered on recheck [20:55:34] And I need to fix a bunch of stuff in my project :( but that was sort of expected [20:55:47] \O/ [20:56:02] bd808: when creating Jenkins job, they sometime do not register with Zuul internal Gearman server :-/ [20:56:13] so you end up with a job failure on recheck [20:56:38] you can tell on gallium by running zuul-gearman.py status |grep whateverjob [20:56:52] that send the 'status' admin command to gearman which list all registered functions, i.e. all jobs [20:57:00] These are legit. jslint looking at things I don't want it to look at and something wrong with my autoloader [20:57:41] for jslint, you need a .jshintrc file [20:57:54] Timo's doc : https://www.mediawiki.org/wiki/Manual:Coding_conventions/JavaScript [20:58:25] marxarel_: any chance you might be around ? :] [20:58:47] hashar: half brainless, but around :) [20:59:08] what's up? [20:59:18] marxarelli: will be quick. We had browser tests running on the labs slaves with firefox in xvfb [20:59:30] with the issue of job dieing randomly because they could no more connect to firefox [20:59:48] looking at our mediawiki_selenium gem and the headless gem, it turns out we always use a display port of 99 [21:00:06] so I suspect that two jobs running on the same instance both use the same display which might cause a whole lot of race condition [21:00:27] and the first job to complete kills the Xvfb causing the other jobs to die because their firefox got killed [21:00:34] so i filled a bug at https://bugzilla.wikimedia.org/show_bug.cgi?id=71602 :] [21:00:46] hope that make sense to your remaining half brain :] [21:02:54] are you able to reproduce the issue? [21:03:52] hashar: i might have to do some digging into how the headless gem invokes xvfb [21:04:51] marxarelli: na I haven't reproduced it. Just highly suspect that is the root cause [21:05:00] might be reproducible in mediawikivagrant [21:05:09] by running a long browser test job, then start a quick one [21:05:24] the end of the quick one should kill display 99 and cause the long one to timeout [21:05:30] (and both firefox to disappears) [21:05:39] hashar: cool, i'll try it out [21:06:05] I suggested potential parameters to pass to Headless.new that might fix it [21:06:56] we can probably get the -sauce jobs to run in parallel would look at it with Zeljkof next week I guess [21:09:02] 3Wikimedia / 3Quality Assurance: mediawiki_selenium always use the same default xvfb display 99 - 10https://bugzilla.wikimedia.org/71602 (10Dan Duvall) 5NEW>3ASSI a:3Dan Duvall [21:10:25] hashar: so, this problem wasn't occurring when we let headless start/stop xvfb? (i.e. before implementing Timo's patch) [21:11:14] marxarelli: we had the firefox timeout issue since we migrated from Cloudbees to our own Jenkins, so before Timo patch [21:11:31] Firehydrant bug is fixed in front of SF office http://imgur.com/a/VCfYH [21:11:45] :) [21:11:56] marxarelli: and Timo xvfb service patch is not deployed yet [21:12:13] Krinkle: is that first image the moment the truck hit the hydrant? [21:12:19] so we do start a new xvfb on the first job, and all the other jobs reuse it [21:12:22] greg-g: A few minutes after, but yes. [21:12:24] that's the truck [21:12:27] hah [21:12:29] hashar: got it. i'll dig in further [21:14:22] Krinkle: you're heading home tomorrow? [21:15:50] Krinkle: really wanted to chat about ci and/or browser testing while you were in town. stupid Death Flu! [21:16:19] I am crashing to bed for now, gottta sleep [21:16:24] g'night hashar [21:16:29] good week-end! [21:16:55] hashar: nighty night [21:17:06] greg-g: how you feeling, btw? [21:17:20] i'm at around 92% [21:17:21] marxarelli: much better [21:17:25] marxarelli: I suspect that we are woefully underpowered to support multiple xvfb processes running multiple Firefox instances inside of them. [21:17:45] greg-g: oh good. that was some shit [21:18:22] marxarelli: yeah, every night I went to bed thinking "tomorrow I'll be better after sleeping for 9 hours" the next day always ended up being "uhhhhhhhhhhhhggggggggggggggghhhhhhhh" [21:20:19] greg-g: werd. i've never had a flu that progressed like that, where i felt more tired and shitty after a good night's sleep [21:20:36] yeah :( so annoying [21:20:36] Project browsertests-VisualEditor-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #312: FAILURE in 1 hr 13 min: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/312/ [21:21:00] anyway, blek. hoping to jump back into everything full steam on monday [21:23:22] chrismcmahon: seems like we need to get headless to reuse xvfb without trying to manage it [21:23:49] the other way around :] [21:24:07] have it managed xvfb, but make sure it create a fresh one instead of reusing one that is going to be killed by a different test running in parallel [21:24:10] marxarelli: I just think the Jenkins hosts keel over when we push them, regardless of how we push them [21:24:24] * chrismcmahon could be wrong [21:24:40] chrismcmahon: you think it's just too many firefox processes? [21:25:38] marxarelli: evidence suggests that we can't run ~8 browser test executors without incurring 90-second timeouts, so I don't have a lot of hope for running multiple xvfb+Firefox [21:26:53] chrismcmahon: what's the bottleneck, cpu, memory, io? [21:27:17] was that 90 timeout when doing http connections? or is that attempting to reach firefox webdriver? [21:27:45] also YuviPanda added a bunch of monitoring metrics for us a month ago or so [21:27:59] so we might be able to look at the instances io/mem/cpu usages while tests are being run [21:28:09] indeed, you can see them now in graphite.wmflabs.org [21:28:12] and confirm whether it is a resource starvation [21:28:18] YuviPanda: Giraffe!!!! :] [21:28:18] marxarelli: I don't know what the bottleneck is. I think it's on our list to figure that out. [21:29:03] chrismcmahon: that is where I am not very helpful. I have no idea how to reproduce the issue :/ [21:29:23] RECOVERY - BetaLabs: Puppet failure events on labmon1001 is OK: OK: All targets OK [21:29:46] hashar: we could un-throttle the browser test executors and see what gets stressed [21:31:06] or create an instance and manually run a bunch of tests to see what happens [21:32:00] back around 2007ish I had a big suite of browser tests that ran serially with xvfb+Firefox. In an effort to improve performance I made them run in parallel, but running parallel actually took LONGER than serial because of load on the host. [21:32:22] so we have to figure out how many we can run in paralel [21:32:37] or get some stronger instances and dedicate them to browsertests [21:32:52] the current ones are shared with a bunch of other jobs that might eat CPU as well [21:33:08] or. we setup a ton of 1 executor instances :] [21:33:11] hashar: giraffe, yeah. not enough time on my hand :( [21:33:31] YuviPanda: I guess Shinken is the priority isn't it ? [21:33:37] yes [21:33:40] I think "get some stronger instances and dedicate them to browsertests" makes a lot of sense [21:33:44] hashar: well, current priority is killing misc/icinga.pp [21:33:49] which is *mostly* done [21:33:53] \O/ [21:34:21] hashar: then is shinken, and then graphing [21:35:15] YuviPanda: sounds like a good roadmap [21:35:24] :) [21:35:39] chrismcmahon: could you raise that on our RelEng or the QA list? [21:35:51] chrismcmahon: we can follow up with zeljkof and others next week this way [21:36:07] for now. I am really going to bed. Have fun [21:52:17] 3Wikimedia / 3Continuous integration: integration/phpunit has an older composer/ClassLoader.php that doesn't understand psr-4 - 10https://bugzilla.wikimedia.org/71629 (10Bryan Davis) 3NEW p:3Unprio s:3normal a:3None The wikimedia/iegreview project is using a PSR-4 autoloading scheme (just like PSR-0... [21:52:46] 3Wikimedia / 3Continuous integration: integration/phpunit has an older composer/ClassLoader.php that doesn't understand psr-4 - 10https://bugzilla.wikimedia.org/71629 (10Bryan Davis) p:5Unprio>3High a:3Bryan Davis [21:59:18] (03PS1) 10BryanDavis: Update to phpunit 3.7.37 and PSR-4 classloader [integration/phpunit] - 10https://gerrit.wikimedia.org/r/164683 (https://bugzilla.wikimedia.org/71629) [22:05:14] (03CR) 10BryanDavis: "I could submit a smaller change that only updates the generated classloader and support files rather than grabbing the latest version of p" (031 comment) [integration/phpunit] - 10https://gerrit.wikimedia.org/r/164683 (https://bugzilla.wikimedia.org/71629) (owner: 10BryanDavis) [22:14:05] (03PS2) 10BryanDavis: Update to phpunit 3.7.37 and PSR-4 classloader [integration/phpunit] - 10https://gerrit.wikimedia.org/r/164683 [22:14:07] (03PS1) 10BryanDavis: Regenerate autoloader [integration/phpunit] - 10https://gerrit.wikimedia.org/r/164687 (https://bugzilla.wikimedia.org/71629) [22:16:11] (03CR) 10BryanDavis: "I made a smaller required change in Ie731eaa7e10548a947d983c0539748fe5a3fe3a2. This will unblock my new project without requiring an upgra" [integration/phpunit] - 10https://gerrit.wikimedia.org/r/164683 (owner: 10BryanDavis) [22:17:00] (03PS3) 10BryanDavis: Update to phpunit 3.7.37 [integration/phpunit] - 10https://gerrit.wikimedia.org/r/164683 [22:18:54] (03CR) 10BryanDavis: Regenerate autoloader (031 comment) [integration/phpunit] - 10https://gerrit.wikimedia.org/r/164687 (https://bugzilla.wikimedia.org/71629) (owner: 10BryanDavis) [22:19:31] greg-g: Would you cane me for deploying a small change to the phpunit infrastructure late on a Friday? -- https://gerrit.wikimedia.org/r/#/c/164687/ [22:19:58] I wouldn't no [22:20:00] Merging should update the labs Jenkins slaves and then I would need to run Trebuchet in prod [22:20:37] I did dial the change down from upgrading phpunit to just rebuilding the autoloader [22:22:01] Ok. I'm bold enough to self-merge the autoloader change then. Last chance to stop me :) [22:22:24] * greg-g coughs and looks the other way [22:22:36] (03CR) 10BryanDavis: [C: 032] Regenerate autoloader [integration/phpunit] - 10https://gerrit.wikimedia.org/r/164687 (https://bugzilla.wikimedia.org/71629) (owner: 10BryanDavis) [22:23:43] nothing to see here folks, move along [22:24:19] ugh. no zuul trigger [22:25:38] So... how do the labs slaves get updated... [22:26:08] * bd808|deploy checks something [22:29:35] Ah. ensure=>latest in the git::clone in puppet [22:29:41] sneaky magic [22:29:51] Ok. back to the show then [22:30:42] (03CR) 10BryanDavis: [V: 032] "Puppet will update the hosts in beta with the contint::slave-scripts role. I'll update the prod hosts via a trebuchet deploy." [integration/phpunit] - 10https://gerrit.wikimedia.org/r/164687 (https://bugzilla.wikimedia.org/71629) (owner: 10BryanDavis) [22:34:26] !log Merged Ie731eaa7e10548a947d983c0539748fe5a3fe3a2 (Regenerate autoloader) to integration/phpunit for bug 71629 [22:34:31] Logged the message, Master [22:34:51] bd808: all good? [22:35:03] hoping so... [22:35:07] :) [22:35:15] my job is queued [22:35:28] back in about an hour, car issue... [22:36:09] ugh. unrelated (I hope) but zuul seems stuck [22:36:45] yeah 158279,9 is stuck [22:37:01] well, jenkins thinks it's done, but zuul doesn't know [22:52:29] 3Wikimedia / 3Continuous integration: Jenkins: Figure out a long term solution to maintaining Jenkins configuration - 10https://bugzilla.wikimedia.org/67027#c3 (10Krinkle) 1. Put the xml file in operations/puppet as template with placeholders for dynamic/private data and ensured in the right location on gall... [22:53:03] !log Had to stop and start zuul due to NoConnectedServersError("No connected Gearman servers") in zuul.log on gallium [22:53:06] Logged the message, Master [22:53:28] greg-g: seems better now [22:53:58] Also, somebody besides hashar needs to really understand this stack [22:54:08] * bd808 is not volunteering [23:01:43] Gah. Yet another thing to configure? What makes a repo merge after Jenkins verifies the commit? [23:02:06] This stack is a fracking pain [23:10:16] 3Wikimedia / 3Quality Assurance: mediawiki_selenium always use the same default xvfb display 99 - 10https://bugzilla.wikimedia.org/71602#c1 (10Dan Duvall) I can repro the reported behavior consistently in MWV using the following feature/steps. Feature: Parallel Tests Scenario: Process 1 When I... [23:18:01] 3Wikimedia / 3Continuous integration: Add Jenkins jobs for iegreview application - 10https://bugzilla.wikimedia.org/71617#c5 (10Bryan Davis) 5PATC>3ASSI This is almost working. Apparently when the gerrit repo was setup JenkinsBot was not given merge permissions greg-g: Who do you poke when you need things fixed in gerrit? I tried the usual suspects on my team and got no responses. :( [23:19:55] I need an admin to grant JenkinsBot and l1on-bot rights on the wikimedia/iegreview repo [23:20:03] *l10n-bot [23:28:29] 3Wikimedia / 3Continuous integration: integration/phpunit has an older composer/ClassLoader.php that doesn't understand psr-4 - 10https://bugzilla.wikimedia.org/71629#c4 (10Bryan Davis) 5PATC>3RESO/FIX Tests needing PSR-4 autoloader are passing now. I left a pending patch for Antoine to look at that woul... [23:45:36] CUSTOM - jenkins_service_running on gallium is OK: PROCS OK: 1 process with regex args ^/usr/bin/java .*-jar /usr/share/jenkins/jenkins.war [23:50:58] (03PS1) 10Dduvall: Additional headless environment variables [selenium] - 10https://gerrit.wikimedia.org/r/164704 (https://bugzilla.wikimedia.org/71602) [23:54:00] (03PS2) 10Dduvall: Additional headless environment variables [selenium] - 10https://gerrit.wikimedia.org/r/164704 (https://bugzilla.wikimedia.org/71602) [23:58:45] 3Wikimedia / 3Quality Assurance: mediawiki_selenium always use the same default xvfb display 99 - 10https://bugzilla.wikimedia.org/71602#c3 (10Dan Duvall) I've submitted a patch that will allow you to provide additional environment variables. Note that simply telling Headless to keep the xvfb process runnin...