To reduce the number of jobs and to test QUnit with all extensions, we should add the qunit step in mediawiki-extensions-{phpflavor}. They would be skipped if the PHPUnit tests fail though.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Jdlrobson | T86687 Thanks is broken again (Mobile Thanks needs qunit tests) | |||
| Declined | None | T88207 Merge extensions PHPUnit and QUnit jobs |
Event Timeline
Comment Actions
That would help making sure extensions do not break each other QUnit tests. For example a mobile extension change breaking Thanks as a side effect ( T86687 ).
Comment Actions
The Qunit step is hitting an Apache / Zend PHP 5.3 service. I am not sure whether it is going to work on the Trusty instances used for the mediawiki-extensions-hhvm job. From a discussion with Timo a few weeks ago, having Zend is enough.
So maybe we should get a third job mediawiki-extensions-qunit that would run both the qunit and qunit-mobile flavors?
Comment Actions
Timo, if you have any good ideas to merge the PHPUnit and Qunit jobs, I would really love them.
Comment Actions
The current *-qunit job template uses the old wmfgrunt global script with grunt-contrib-qunit (which uses PhantomJS) and currently pinned to production slaves running Ubuntu Precise. For many reasons I'm migrating this to use Karma (T74063).
I did 99% of T74063, but it's currently stalled due to environmental problems with sqlite and MediaWiki core (T89180). That aside, I completed migration of the backend for these jobs to run on Ubuntu Trusty. The necessary changes have been puppetised and deployed, and Jenkins job macros were also accommodated (e.g. the mediawiki bootstrapping and qunit localhost). The front-end has also be re-implemented, deployed and enabled but currently non-voting due to the aforementioned issues.
Once that is resolved, we should be able to quite easily merge these jobs by combining their builder macros.
I'm not yet convinced that it's desirable or appropriate to do the same kind of extension combining for QUnit jobs, however.
Comment Actions
So AIUI we basically want to add the "qunit-karma" builder to the mediawiki-extensions-* jobs after phpunit is run?
Comment Actions
The qunit job was instead combined with the selenium job. I don't think combining it with PHPUnit as well would be beneficial a adding those together would start to regress our total time to get results from Jenkins (from 5-10min to probably 6-15min; larger range due to loss in concurrency).
MediaWiki core could probably reduce load on Nodepool by combining or removing jobs, but I'd recommend exploring smaller jobs to be combined instead.
pipeline:test project:mediawiki/core.git
mediawiki-extensions-hhvm-jessie SUCCESS in 5m 18s mediawiki-extensions-qunit-jessie SUCCESS in 3m 11s mediawiki-core-jsduck SUCCESS in 46s mediawiki-core-npm-node-6-jessie SUCCESS in 1m 50s mediawiki-core-php55lint SUCCESS in 5s mediawiki-phpunit-hhvm-jessie SUCCESS in 2m 32s mediawiki-core-qunit-selenium-jessie SUCCESS in 2m 18s mediawiki-core-php70-phan-jessie SUCCESS in 1m 28s
Good combination candidates:
- npm-node and jsduck
- php55lint and php70-phan
@hashar Perhaps even add all 4 together? They're relatively small, and their total will still be shorter than the longest job which means it won't impact "time to result" for developers, but still save significant resources for Nodepool instances and Zuul cloning.