Hello,
We have a mediawiki/vendor repository that holds third party libraries. Since MediaWiki core is going to eventually rely on them I have crafted a new Jenkins job (mediawiki-vendor-integration) which clones both repositories, checkout the appropriate patch / branch and run the whole MediaWiki PHPUnit test suite.
The job is triggered when a patch is proposed on either mediawiki/core or mediawiki/vendor but only for the master and REL* branches for now. I have made it non voting.
The job takes roughly 6 minutes that will slightly delay the report to Gerrit.
If the job looks fine. The next steps are:
- make it pass on wmf branches - trigger it run on CR+2
Then, I will be able to phase out the grouped PHPUnit groups and the sqlite installer tester. Long term: have the tests to run using HHVM as well.
On Wed, Aug 20, 2014 at 7:58 AM, Antoine Musso hashar+wmf@free.fr wrote:
Hello,
We have a mediawiki/vendor repository that holds third party libraries. Since MediaWiki core is going to eventually rely on them I have crafted a new Jenkins job (mediawiki-vendor-integration) which clones both repositories, checkout the appropriate patch / branch and run the whole MediaWiki PHPUnit test suite.
A huge thanks from me personally for all the work that Antoine has put in on this. My initial email to him about the idea and problem was something like "I'm sure this won't be too hard, where should we start?" Little did I know that it would lead to a non-trivial upstream patch to extend zuul [0], a local zuul upgrade or two, many attempts to integrate the new tool with our pipeline [1] and i-don't-know-how-much of Antoine's "spare" time.
The world where we can use Composer manager libraries with MediaWiki on the Foundation's servers is another step closer to reality. The tests including the vendor checkout [2] for my PSR-3 logging patch [3] are now passing for the first time. :)
[0]: https://review.openstack.org/#/c/70373/ [1]: https://gerrit.wikimedia.org/r/#/c/141819/ [2]:https://integration.wikimedia.org/ci/job/mediawiki-vendor-integration/37/con... [3]: https://gerrit.wikimedia.org/r/#/c/119941/
Bryan
Le 20/08/2014 15:58, Antoine Musso a écrit : <snip>
If the job looks fine. The next steps are:
- make it pass on wmf branches
- trigger it run on CR+2
Then, I will be able to phase out the grouped PHPUnit groups and the sqlite installer tester. Long term: have the tests to run using HHVM as well.
I have made the job mediawiki-vendor-integration voting and it is now being triggered on CodeReview +2. I have disabled the legacy phpunit groups jobs as well as the sqlite installer, all are covered by the new job.
wmf branches remain untouched.
Will have to adjust the qunit job to use mediawiki/vendor as well.
Great news! Hope this will come to extension/ too soon. We have got composer installed dependencies both in SwiftMailer[1] and BounceHandler[2]. We even had to make a no-dependency-workaround ready in Bouncehandler to make sure that it works without $composer update. Still remember that long threads we had on swiftmailer earlier :)
It would be great, if we can install default skins too in this fashion. I just found the new installation mode of copying manually libraries to skins/ a bit difficult, thats why. [1]https://www.mediawiki.org/wiki/Extension:SwiftMailer [2] https://www.mediawiki.org/wiki/Extension:BounceHandler
Thanks, Tony Thomas http://tttwrites.wordpress.com/ FOSS@Amrita http://foss.amrita.ac.in
*"where there is a wifi, there is a way"*
On Tue, Aug 26, 2014 at 7:19 PM, Antoine Musso hashar+wmf@free.fr wrote:
Le 25/08/2014 14:55, Antoine Musso a écrit :
Will have to adjust the qunit job to use mediawiki/vendor as well.
The mediawiki-core-qunit job is now cloning mediawiki/vendor as well :]
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org