Last modified: 2014-11-15 17:34:02 UTC
Relevant files: https://github.com/wikimedia/integration-jenkins/blob/0b85d48e60/bin/wmfgrunt https://github.com/wikimedia/integration-jenkins/blob/0b85d48e60/tools/Gruntfile.js Be sure to fetch integration-jenkins locally to test it as it's customised. If you don't run Linux Precise, first cd ./tools; rm -rf node_modules and npm-install will provide for your system. Then https://github.com/wikimedia/integration-config/blob/0b85d48e60/jjb/macro.yaml#L344 is where it's invoked. That command can be run against your localhost.
Change 168631 had a related patch set uploaded by Krinkle: [WIP] contint: Apply contint::qunit_localhost to labs slaves https://gerrit.wikimedia.org/r/168631
Step 1: Move qunit from prod/precise to labs/trusty. Step 1a: Refactor puppet for localhost/qunit and apply to labs. Step 1b: Refactor puppet for mediawiki testing and apply to labs (sqlite, php5-cli, imagemagic, etc.) Step 2: Change integration/jenkins:bin/wmfgrunt to use Karma instead of Grunt-contrib-qunit/grunt-lib-phantomjs localhost/qunit: * https://gerrit.wikimedia.org/r/#/c/170792/ * https://gerrit.wikimedia.org/r/#/c/168630/ * https://gerrit.wikimedia.org/r/#/c/168631/ Looks like the qunit test doesn't pass in labs. Some seeminly-random API calls are failing. https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit2/6/console
I've copied one of the qunit2 jobs to a static directory on integration-slave1008 and proxied it through ssh to my local Chrome to use Dev Tools to investigate the QUnit failures. They are indeed timing out, on load.php requests. Some of which are taking over 12 seconds (the QUnit timeout for an individual test is 10 seconds, defined in our testrunner.js in mediawiki-core:/tests/qunit/data). The main slowdown is the database layer. Increasing the timeout to 30 seconds made it work, but we don't want our tests to be that slow. I'll first try to match production speed more, and we could resort to increasing the timeout otherwise. Will add a tmpfs to the integration slaves and make Jenkins use that when appropriate.
Change 173512 had a related patch set uploaded by Krinkle: [WIP] contint: Add tmpfs mount in jenkins-deploy homedir for labs slaves https://gerrit.wikimedia.org/r/173512
The sqlite installer auto-detects presence of a tmpfs mount in $HOME via mw-set-env: https://github.com/wikimedia/integration-jenkins/blob/8abc7b6/bin/mw-set-env.sh#L19 I've mounted tmpfs drive in the $HOME of jenkins-deploy on the integration slaves https://gerrit.wikimedia.org/r/173511 https://gerrit.wikimedia.org/r/173512
Tested a few in labs, and are now running fine. The compared runs in labs are an N+1 run since the first one involve zuul-cloner cloning mediawiki-core. -- on gallium in 1m18s: https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/12309/ on integration-slave1003 in 1m34s: https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/12365/ -- on gallium in 1m23s: https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/12362/ on integration-slave1003 in 1m31s: https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/12366/ -- on gallium in 29s: https://integration.wikimedia.org/ci/job/mediawiki-core-qunit/32092/ on integration-slave1003 in 32s: https://integration.wikimedia.org/ci/job/mediawiki-core-qunit/32094/
Change 173529 had a related patch set uploaded by Krinkle: Migrate mediawiki/qunit jobs from production slaves to labs https://gerrit.wikimedia.org/r/173529
