There are third party extensions that interact tightly with MediaWiki core, and suffer directly the consequences of changes in core. These extensions need
Daniel Friesen explains the case of the DumpHTML extension, as mentioned in T392#6179. Let's use this extension as an example to document this problem and agree on the best practices to solve them.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T76896 Wiki Release Team First Quarter 2015 Quarterly Review | |||
| Resolved | Qgil | T76672 Wiki Release Team December Goals | |||
| Resolved | Qgil | T782 Wiki Release Team November 2014 Goals | |||
| Resolved | • demon | T529 Automate patch application for tests for QA part of make_release | |||
| Resolved | Mglaser | T537 Wiki Release Team October 2014 goals | |||
| Duplicate | MarkAHershberger | T530 Document QA requirements of MediaWiki releases | |||
| Resolved | MarkAHershberger | T492 Document the QA process for MediaWiki releases | |||
| Declined | MarkAHershberger | T536 Take DumpHTML as a use case of 3rd party extension that MediaWiki maintainers cannot ignore |
We could use DumpHTML to act as a sort of "canary in the coal mine" and let us know when extensions need work. We could also update it and the example extensions with some tests that the test harness run.
I have edited the task to make it clearer. This doesn't mean that I'm asking you to do so. Like any other task, first of all is a proposal. You will decide wether you accept it or decline it, and if you accept it, when will you work on it.
From https://gerrit.wikimedia.org/r/#/c/168207/
Extensions may add tests by directory
The UnitTestsList hook can now be used to add entire directories of
tests, à la phpunit.xml's <directory> tag. The test suite is built by
recursively scanning the directory for any files ending in "Test.php".
We are in the process of making a Jenkins pre-merge job that runs all of the WMF deployed extensions unit tests for a commit in either MW Core or any of those other extensions (see T69216). Lobbying for another extension to be added to that group should be made on a case-by-case basis. I move to close this task as "decline" and move forward more positively.
greg writes:
I move to close this task as "decline" and move forward more positively.
I'm fine with "decline" but I would like to understand what you mean by
"move forward positively".
The phrase "use case ... MW maintainers cannot ignore" just sounds antagonistic, is all.
If an extension needs to (absolutely) be working with MW master at all times, it simply should have unit/integration tests associated with it that are voting for for a merge into core. Right now we have a job that has (many of) the WMF deployed extensions doing that so that we don't break production accidentally. We can do similarly for "MW tarball" use cases if need be.
That change/proposal should go in the CI Config project, when it is ready to be proposed.