Failed asserting that an array does not have the key 'warnings'.

Would be useful if PHPUnit dumped the contents of the warnings, of course…

Adding Language::getLocalisationCache()->unloadAll(); in setUp() might help – is there any way to test it on Travis CI without merging such a change to master? Perhaps push it to a branch on GitHub?

In T225244#5242449, @Lucas_Werkmeister_WMDE wrote:

Adding Language::getLocalisationCache()->unloadAll(); in setUp() might help – is there any way to test it on Travis CI without merging such a change to master? Perhaps push it to a branch on GitHub?

If you do a github PR it should do so...

I opened #101, but the Travis pull requests page says “no pull request builds for this repository”, and the “requests” list explains:

Build type disabled via repository settings (pull_request).

In T225244#5242986, @Lucas_Werkmeister_WMDE wrote:

I opened #101, but the Travis pull requests page says “no pull request builds for this repository”, and the “requests” list explains:

Build type disabled via repository settings (pull_request).

I've just turned it on again... Want to try doing something to trigger it to try again? Push another commit ontop of it, or force push a rebase or something

repo admin can configure whether to test PR. Looks like it is disable in wikimedia/mediawiki.

Now it’s building, thanks.

Okay, the Language::getLocalisationCache()->unloadAll(); doesn’t seem to make a difference. But I can keep trying more things (and adding debug code) on GitHub now that pull request building is enabled… though I don’t know how much time I’ll have for this :/

What’s the priority of this task, by the way? Do lots of people depend on the Travis CI builds?

The key is that the Travis CI builds includes a full test of phpunit, and the error also appeared in my test environment.

In T225244#5243487, @RazeSoldier wrote:

The key is that the Travis CI builds includes a full test of phpunit, and the error also appeared in my test environment.

What is that supposed to mean? That we don't run all the phpunit tests in WMF CI?

In T225244#5243466, @Lucas_Werkmeister_WMDE wrote:

Okay, the Language::getLocalisationCache()->unloadAll(); doesn’t seem to make a difference. But I can keep trying more things (and adding debug code) on GitHub now that pull request building is enabled… though I don’t know how much time I’ll have for this :/

What’s the priority of this task, by the way? Do lots of people depend on the Travis CI builds?

I don't actually know what the priority is.

We don't depend on them, but we try and avoid them being broken (and therefore fixing them when we know they are broken). They're usually a good source of edge case failures (like this one), so obviously should be fixed

In T225244#5243541, @Reedy wrote:

In T225244#5243487, @RazeSoldier wrote:

The key is that the Travis CI builds includes a full test of phpunit, and the error also appeared in my test environment.

What is that supposed to mean? That we don't run all the phpunit tests in WMF CI?

Looks WMF CI just test Database group

php tests/phpunit/phpunit.php --debug-tests --group Database --exclude-group Broken,ParserFuzz,Stub --log-junit /workspace/log/junit-db.xml

and the Travis CI:

php tests/phpunit/phpunit.php

A full test should contain 20,000+ tests.

In T225244#5243560, @RazeSoldier wrote:

In T225244#5243541, @Reedy wrote:

What is that supposed to mean? That we don't run all the phpunit tests in WMF CI?

Looks WMF CI just test Database group

php tests/phpunit/phpunit.php --debug-tests --group Database --exclude-group Broken,ParserFuzz,Stub --log-junit /workspace/log/junit-db.xml

It looks that way, but that's because in WMF CI we run the PHPUnit tests in two parts (to give faster responses). The last part, which you might see at the end of the Jenkins output, is for "group Database". The first part, is for the other groups.

Change 516280 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] api: Temporarily disable ApiQueryLanguageinfoTest

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

Change 516280 merged by jenkins-bot:
[mediawiki/core@master] api: Temporarily disable ApiQueryLanguageinfoTest

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

Regarding the actual issue, my guess is that it is a difference between whether the cldr extension is available or not when the tests are run.

In T225244#5243466, @Lucas_Werkmeister_WMDE wrote:

Okay, the Language::getLocalisationCache()->unloadAll(); doesn’t seem to make a difference. But I can keep trying more things (and adding debug code) on GitHub now that pull request building is enabled… though I don’t know how much time I’ll have for this :/

Poking at things locally a little bit, I can reproduce the errors when I run all API tests rather than just the one file. It looks like you were on the right track, but clearing the wrong cache. It seems what actually needs clearing is Language::$languageNameCache, which can be cleared with Language::clearCaches(). If you want to submit that to Github for verification, please do.

It seems all the tests that run before this one and trigger that cache population (e.g. ApiParseTest) are marked as "Database", so Wikimedia's CI that runs Database and non-Database separately doesn't run into it.

Thanks! I updated #101 accordingly – so far the Travis job is stuck being queued, but hopefully it’ll start soonish and tell us whether that fully fixes the problem.

Change 516590 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/core@master] Fix and re-enable ApiQueryLanguageinfoTest

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

Travis build succeeded except for the PHP 7.3 version, but that seems to be failing for unrelated reasons.

In T225244#5252425, @Lucas_Werkmeister_WMDE wrote:

Travis build succeeded except for the PHP 7.3 version, but that seems to be failing for unrelated reasons.

7.3 is “allowed to fail”, for now...

The 7.3 failure in https://travis-ci.org/wikimedia/mediawiki/jobs/544313531 is T207100: LanguageTrTest::testDottedAndDotlessI fails in PHP 7.3.

Change 516590 merged by jenkins-bot:
[mediawiki/core@master] Fix and re-enable ApiQueryLanguageinfoTest

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

I guess building of pull requests should now be turned off again.

In T225244#5254053, @Lucas_Werkmeister_WMDE wrote:

I guess building of pull requests should now be turned off again.

Done.

For future reference, you can also trigger these builds from your GitHub fork directly without needing to create a pull request first. To do so, from travis-ci.org enable builds for your repository. Then the builds will work as long as they are in your master branch or the branch is named "travis-ci/something". Alternatively, as part of your commit remove the brach filter in travis.yml to have it work for any branch in your personal repo.