Le 10/04/2014 07:43, Rob Lanphier a écrit :
I have a working session with Dan tomorrow to do major work on the wiki page here: https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_revie...
Mail is all about hhvm
== testing ==
For hhvm we have a lot of cross dependencies. I would love us to come with an integration test plan to make sure that a new HHVM version does not break the ported PHP extensions and that the PHP extensions are compatible with the tip of hhvm as well as the deployed version.
Zuul has supports for cross repositories dependencies. I am working on a patch to make it easy to fetch the proper versions on each repository which would let us write nice integration jobs.
The idea would be roughly:
a change is made to hhvm@<branch> - trigger job to build hhvm@<branch> + proposed patch - trigger jobs for each of the extension@<branch> against the patched hhvm
a change is made to extension@<branch> - trigger jobs to build that patched extension against hhvm@<branch>
We could also have job to make sure a change made to an extension@master remains compatible with the hhvm@production.
== hhvm tweaks to execute tests ==
Still on hhvm front, there is a lot of various configuration settings. We run the MediaWiki core PHPUnit tests with:
Eval.Jit=1 Debug.CoreDumpReportDirectory="$LOG_DIR" Repo.Central.Path="$WORKSPACE/hhvm.hhbc.sqlite"
There is probably a lot more settings we should set there or on the future application servers.
Ie:
hhvm -vEval.Jit=1 \ -vDebug.CoreDumpReportDirectory="$LOG_DIR" \ -vRepo.Central.Path="$WORKSPACE/hhvm.hhbc.sqlite" \ --php phpunit.php \ --with-phpunitdir "$PHPUNIT_DIR" \ --conf "$MW_INSTALL_PATH/LocalSettings.php" \ --log-junit $JUNIT_DEST
https://github.com/wikimedia/integration-jenkins/blob/master/bin/mw-run-phpu...
== target architecture ==
We would need to brainstorm about the targeted architecture and how to migrate to it. I dont think we can run PHP/Apaches and hhvm on the same boxes. Potentially we could have a whole new cluster of hhvm application servers and have Varnish routes requests to hhvm based on a switch (maybe a betafeatures cookie?).