Page MenuHomePhabricator

Merge extensions PHPUnit and QUnit jobs
Closed, DeclinedPublic


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.

Event Timeline

hashar raised the priority of this task from to Needs Triage.
hashar updated the task description. (Show Details)
hashar added a subscriber: hashar.

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 ).

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?

Timo, if you have any good ideas to merge the PHPUnit and Qunit jobs, I would really love them.

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.

Krinkle set Security to None.

So AIUI we basically want to add the "qunit-karma" builder to the mediawiki-extensions-* jobs after phpunit is run?

Krinkle closed this task as Declined.EditedJul 13 2017, 4:54 AM

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.