Page MenuHomePhabricator

Enable mediawiki-quibble-apitests-vendor-docker for extension Math
Closed, ResolvedPublic

Description

Follow this guide for Math.

Event Timeline

Change 599963 had a related patch set uploaded (by Physikerwelt; owner: Physikerwelt):
[integration/config@master] Enable API tests for extension Math

https://gerrit.wikimedia.org/r/599963

Change 599963 merged by jenkins-bot:
[integration/config@master] Enable API tests for extension Math

https://gerrit.wikimedia.org/r/599963

Reedy subscribed.

Deployed

Change 601427 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[integration/config@master] layout: [mediawiki/extensions/Math] Disable API tests, not passing yet

https://gerrit.wikimedia.org/r/601427

Change 601427 merged by jenkins-bot:
[integration/config@master] layout: [mediawiki/extensions/Math] Disable API tests, not passing yet

https://gerrit.wikimedia.org/r/601427

Mentioned in SAL (#wikimedia-releng) [2020-06-01T20:49:46Z] <James_F> Zuul: Disabled new mediawiki-quibble-apitests-vendor-docker for Math as it doesn't pass T254031

Jdforrester-WMF subscribed.

Undeployed. This job isn't passing yet. Please un-mark as stalled if and when the experimental job passes so we can re-enable it.

The search tests are failing because Math depends on Wikibase in CI, which in turn brings in CirrusSearch as a dependency.

Running api-testing search tests with CirrusSearch installed fails for some reason. I couldn't really find anything very relevant in the logs to explain why exactly is it failing.

eprodromou subscribed.

We think this is big enough that it should be its own small project.

We think this is big enough that it should be its own small project.

How is project different from a subtask, such as enable API tests for CirrusSearch?

Currently, we see the following error.

17:49:25   5 failing
17:49:25 
17:49:25   1) Search
17:49:25        GET /search/page?q={term}
17:49:25          should return array of pages when there is only a text match:
17:49:25 
17:49:25       AssertionError: expected [] to have a length of 1 but got 0
17:49:25       + expected - actual
17:49:25 
17:49:25       -0
17:49:25       +1
17:49:25       
17:49:25       at Context.it (tests/api-testing/REST/Search.js:31:11)
17:49:25       at process._tickCallback (internal/process/next_tick.js:68:7)
17:49:25 
17:49:25   2) Search
17:49:25        GET /search/page?q={term}
17:49:25          should return array of pages when there is only title match:
17:49:25 
17:49:25       AssertionError: expected [] to have a length of 1 but got 0
17:49:25       + expected - actual
17:49:25 
17:49:25       -0
17:49:25       +1
17:49:25       
17:49:25       at Context.it (tests/api-testing/REST/Search.js:50:11)
17:49:25       at process._tickCallback (internal/process/next_tick.js:68:7)
17:49:25 
17:49:25   3) Search
17:49:25        GET /search/page?q={term}
17:49:25          should return a single page when there is a title and text match on the same page:
17:49:25 
17:49:25       AssertionError: expected [] to have a length of 1 but got 0
17:49:25       + expected - actual
17:49:25 
17:49:25       -0
17:49:25       +1
17:49:25       
17:49:25       at Context.it (tests/api-testing/REST/Search.js:61:11)
17:49:25       at process._tickCallback (internal/process/next_tick.js:68:7)
17:49:25 
17:49:25   4) Search
17:49:25        GET /search/page?q={term}
17:49:25          should return two pages when both pages match:
17:49:25 
17:49:25       AssertionError: expected [] to have a length of 2 but got 0
17:49:25       + expected - actual
17:49:25 
17:49:25       -0
17:49:25       +2
17:49:25       
17:49:25       at Context.it (tests/api-testing/REST/Search.js:72:11)
17:49:25       at process._tickCallback (internal/process/next_tick.js:68:7)
17:49:25 
17:49:25   5) Search
17:49:25        GET /search/page?q={term}
17:49:25          should return only one page when two pages match but limit is 1:
17:49:25 
17:49:25       AssertionError: expected [] to have a length of 1 but got 0
17:49:25       + expected - actual
17:49:25 
17:49:25       -0
17:49:25       +1
17:49:25       
17:49:25       at Context.it (tests/api-testing/REST/Search.js:79:11)
17:49:25       at process._tickCallback (internal/process/next_tick.js:68:7)

from https://integration.wikimedia.org/ci/job/mediawiki-quibble-apitests-vendor-docker/10701/console
I mean it is not really surprising that the search results differ based on the search engine. And from the test results, it seems that the data is not (yet?) ready to be queried by CS. To me, there is a pressing need for a CI test that runs all tests with all WMF deployed extensions enabled that is triggered for every core change... Maybe it consumes too much energy, but it would reduce the debugging effort after the fact.

We think this is big enough that it should be its own small project.

After talking to @Physikerwelt, this seems like a simple CI config change to me. I don't think it has anything to do with us. I'll untag PET for now It's already on the CI config board.

Running api-testing search tests with CirrusSearch installed fails for some reason. I couldn't really find anything very relevant in the logs to explain why exactly is it failing.

End-to-end tests for search will fail with CirrusSearch installed because CIrrusSearch needs an Elastic service to back it up. We don't have that in CI. The API tests for core are explicitly written to work with a vanilla install only.

For the math extension, I see two solutions: either run only the API tests for Math, not the ones for core. Or only enable the Math extension for Jenkins job that runs the API tests, not other extensions. I'm not sure how simple or hard either one is to do in quibble, but that would make it work. I hope we don't need T243976 for this.

To me, there is a pressing need for a CI test that runs all tests with all WMF deployed extensions enabled that is triggered for every core change... Maybe it consumes too much energy, but it would reduce the debugging effort after the fact.

Yes, sure, in some bright an shiny future. See T248683: Create and run a suite of end-to-end tests for the Wikimedia environment

Physikerwelt changed the task status from Stalled to Open.Nov 6 2020, 6:30 AM
Physikerwelt assigned this task to Jdforrester-WMF.

The API tests do no longer fail on an experimental run (https://integration.wikimedia.org/ci/job/mediawiki-quibble-apitests-vendor-docker/23533/console). See https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/639630
However, there are two new problems both seem to be related to the test DB config.

I suspect that those errors are due to other experimental run features that would not occur if we would switch on the API tests for the normal test run.

Change 639651 had a related patch set uploaded (by Physikerwelt; owner: Physikerwelt):
[integration/config@master] Revert "layout: [mediawiki/extensions/Math] Disable API tests, not passing yet"

https://gerrit.wikimedia.org/r/639651

However, there are two new problems both seem to be related to the test DB config.

That job uses SQLite as a database backend? We used to only test with SQLite until in 2015 we switched everything to use MySQL (T37912 / 2957704054eabc1ef2ffc59b2cb62754a14b0714). Nowadays SQLite is only enforced for mediawiki/core.

I suspect that those errors are due to other experimental run features that would not occur if we would switch on the API tests for the normal test run.

That job uses PostgreSQL. GeoData has been written with MySQL in mind and support for SQLite was added in 2012 by a8cb327bf078cb7b653dff18e04464beceeca5b8 which also reject any other database backend. The change passed with MySQL though.


What is important in the experimental result is that the api testing job (mediawiki-quibble-apitests-vendor-docker) did pass. One would still want to ensure it ran the expected tests

Change 639651 merged by jenkins-bot:
[integration/config@master] Revert "layout: [mediawiki/extensions/Math] Disable API tests, not passing yet"

https://gerrit.wikimedia.org/r/639651

Physikerwelt added a subscriber: Naike.

@Naike, this task was already resolved by @hashar on Nov 7th