Page MenuHomePhabricator

fix the qunit tests for wikidata: mwext-Wikibase-qunit
Closed, ResolvedPublic

Description

Fix the qunit tests for wikidata: mwext-Wikibase-qunit and after that make them voting.


Version: wmf-deployment
Severity: normal
Whiteboard: u=dev c=qa p=0

Details

Reference
bz72184

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:45 AM
bzimport set Reference to bz72184.
bzimport added a subscriber: Unknown Object (MLST).

It seems /srv/localhost/qunit/ is missing on the instances. That is created by puppet class contint::qunit_localhost which is not applied on that host. It is only applied in role::ci::slave and not anything that is applied on labs (like role::ci::slave::labs). So the jenkins slave selector in that jobs config might need adjusting (if there is a qunit specific one, see other qunit jobs) and contint::qunit_localhost should also be applied on (some?) jenkins labs instances.

gerritadmin wrote:

Change 171535 had a related patch set uploaded by Adrian Lang:
Add qunit localhost setup to role::ci::slave::labs

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

Don't do that. This job should not be running in labs to begin with. Installing mediawiki and serving it from Apache for a qunit testing, grunt, and correct node and phantomjs version has not been done yet for labs.

See bug 72063 for that (which I'm already working on).

If composer now works on production jenkins slave, droping the wikidata jenkins slave selector and adding the one for qunit might work.

OK contint::slave-scripts which is what installs composer on labs isn't supposed to run in production. That should not be changed, so no way for us to run the qunit tests unless they run in labs.

(In reply to Jan Zerebecki from comment #5)

OK contint::slave-scripts which is what installs composer on labs isn't
supposed to run in production. That should not be changed, so no way for us
to run the qunit tests unless they run in labs.

For mediawiki-core this is solved by using mediawiki-vendor, just like we do in production. How does wikidata run in production without composer?

For extensions/Wikibase.git composer is one of the things run during build time, the whole build result is commited to extensions/Wikidata.git which is what gets deployed. Independent of that there are many dependencies that are updated often so that integration runs without running composer are much less useful.

gerritadmin wrote:

Change 171535 abandoned by Adrian Lang:
Add qunit localhost setup to role::ci::slave::labs

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

Just in case anyone was wondering: During T73419 I moved this job from the wikidata slaves to the normal labs slaves.
Compare before: https://integration.wikimedia.org/ci/job/mwext-Wikibase-qunit/4902/console
After: https://integration.wikimedia.org/ci/job/mwext-Wikibase-qunit/4903/console
It now fails with:
16:48:35 >> PhantomJS timed out, possibly due to a missing QUnit start() call.

On the Wikidata slave, the job were failing because they were not able to set up the env properly:

ln: failed to create symbolic link `/srv/localhost/qunit/jenkins-mwext-Wikibase-qunit-4902': No such file or directory

Now it is some QUnit error, so that is step forward!

Downloading the log artefacts shows there are only two errors:

# --- mw-dberror.log (3 lines)
integration-slave1003	build4924	SqlBagOStuff::set/single-row		5	database is locked
   REPLACE INTO objectcache (keyname,value,exptime) VALUES ('build4924:resourceloader:modulemodifiedhash:startup:a51e88377de6e214bb3e8742a98d3e6b',x'15..3f','20..07')

# --- mw-error.log (7000 lines)
integration-slave1003 build4924: [0bc103a0] /jenkins-mwext-Wikibase-qunit-4924/index.php?title=Special:BlankPage
  ErrorException from line 376 of includes/debug/logger/legacy/Logger.php:
  PHP Warning: file_put_contents(mw-debug.log): failed to open stream: Permission denied
JanZerebecki set Security to None.
JanZerebecki moved this task from incoming to ready to go on the Wikidata board.

Currently all the HTTP responses inside that jobs have size 0, i.e. no content. Probably should add the apache error log to the build artifacts to be able to find out why.

[…] Probably should add the apache error log to the build artifacts to be able to find out why.

Who is going to do that?

Running the qunit tests with --force, gives more errors most of which seem not to be related to the sqlite locking issue: https://integration.wikimedia.org/ci/job/mwext-Wikibase-qunit-experiment/8/consoleFull

Correction it wasn't the force that made it work more, it was the added setting: $wgResourceLoaderMaxQueryLength = 4096;
That is tracked in T90453.
Log of that run: https://integration.wikimedia.org/ci/job/mwext-Wikibase-qunit-experiment/10/consoleFull

The focusing tests fail. We should either try to detect if they could possibly pass and otherwise skip them or remove them altogether. @Tobi_WMDE_SW @Snaterlicious @WMDE-Fisch What do you think – Do we need these tests?

Aside from that, some ExpertExtender and entitytermsforlanguagesview tests fail, and various tests fail with »mw.WbTemplate: Wrong parameter type. Pass either String or jQuery.«. I don't get what happens there, but I guess reproducing the test job locally will help investigating that. Probably running grunt qunit is sufficient for reproducing the failures. I'll happily do that if nobody beats me to it.

Regarding the focus tests, IIRC we talked about removing them quite some times. Think we also agreed that they don't make much sense either. So I'm all for removing them. But I'm not sure if there are not also focus tests from core. Are they failing too?

AFAIK we are the only ones with focus tests.

The failing ExpertExtender tests also need focus apparently.

[…] Probably should add the apache error log to the build artifacts to be able to find out why.

Who is going to do that?

No need. As of recent, MediaWiki collects PHP notices and warnings (with stack traces, unlike the default stderr sent to apache error log) and exceptions and writes these to log files. (See also T50002 and T45086.)

If these logs fail to be created or if they are misconfigured, then this error is in the build output, or in the few logs that did succeed.

Previously, Wikibase was wrongly overwriting Jenkins' MediaWiki base settings (Fixed in 0a35ec5d1f3). As such it failed to write to the log file. The failure to write to this file was exposed in mwext-Wikibase job's debug log from the beginning. But since the name of the file was too similar to the default one, we didn't realise it was actually the wrong path. It seemed like an infrastructure issue in Jenkins of not having the right permissions, but really Wikibase had tampered with the destination file path.

https://integration.wikimedia.org/ci/job/mwext-Wikibase-qunit/ collects build artefacts. If any mw-errors.log, exceptions and debug were created during the build, they are viewable there for 30 days.

Example: https://integration.wikimedia.org/ci/job/mwext-Wikibase-qunit/7509/

Build Artifacts

  • LocalSettings.php 10.02 KB view
  • mw-dberror.log 303 B view
  • mw-debug-cli.log 1.10 KB view
  • mw-debug-www.log 120.75 KB view
  • mw-error.log 8.10 KB view
  • mw-exception.log 1.77 KB view

Needs release of ValueView and $wgResourceLoaderMaxQueryLength set.

How do you know they failed because of the database locked errors? They too show the "0/0 assertions warning" symptom.

Sorry. It's way down in the mw-debug-www.log build artifact.

Passing, all changes merged. Next step is to make the job voting: T92946

Tobi_WMDE_SW claimed this task.
Tobi_WMDE_SW moved this task from Review to Done on the § Wikidata-Sprint-2015-03-11 board.