Page MenuHomePhabricator

Proof-of-concept: Run MediaWiki tests in latest Zuul
Open, Needs TriagePublic

Description

The latest Zuul changes a lot about how jobs are defined. We need to have some assurance that we can run MediaWiki tests there.

Running Quibble there is a good step.

Here is the full list of jobs that runs for the mainline branch of MediaWiki in our existing Zuul:

castor-save-workspace-cachersync for Castor surely the caching would be handled differently
mediawiki-core-javascript-docker-publish
mediawiki-core-php74-phan-dockerphan
mediawiki-core-php80-phan-dockerphan
mediawiki-core-php81-phan-dockerphan
mediawiki-fresnel-patch-dockerFresnel
mediawiki-i18n-check-dockerA grep
mwcore-codehealth-master-non-votingWith SonarQube for reporting
mwcore-codehealth-patchWith SonarQube for reporting
mwcore-phpunit-coverage-patch
mwgate-node16-dockerMerely runs npm ci && npm test
php-composer-security-docker
publish-to-docrsync to doc.wikimedia.org
selenium-daily-beta-MediaWikiWebdriver.io tests against Beta-Cluster-Infrastructure
selenium-daily-betacommons-MediaWikiWebdriver.io tests Beta-Cluster-Infrastructure
trigger-mediawiki-pipeline-publish

The jobs below are based on Quibble, they invoke the CI image passing ZUUL environment variables, different options to Quibble and set of dependencies to clone based on integration/config zuul/parameters_functions.py

mediawiki-quibble-apitests-vendor-php74-docker
mediawiki-quibble-composer-mysql-php74-docker
mediawiki-quibble-composer-mysql-php80-docker
mediawiki-quibble-composer-mysql-php81-docker
mediawiki-quibble-composertest-php74-docker
mediawiki-quibble-selenium-vendor-mysql-php74-docker
mediawiki-quibble-vendor-mysql-php73-docker
mediawiki-quibble-vendor-mysql-php74-docker
mediawiki-quibble-vendor-mysql-php80-docker
mediawiki-quibble-vendor-mysql-php81-docker
mediawiki-quibble-vendor-postgres-php74-docker
mediawiki-quibble-vendor-sqlite-php74-docker
quibble-vendor-mysql-php74-phpunit-standalone-docker(no idea)
wmf-quibble-core-vendor-mysql-php74-docker
wmf-quibble-core-vendor-mysql-php81-docker
wmf-quibble-selenium-php74-docker
wmf-quibble-selenium-php81-docker

Many are doing similar things. This task entails:

  1. Understanding the jobs above
  2. Getting a subset of them running as a proof-of-concept in the new Zuul system
  3. Documenting anything that needs more thought

It's a big task, so breaking it down by job-group is probably appropriate.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

First step is probably to dedupe this huge list into a critical subset of jobs.

Simplest to start with: Remove the three php80 ones per T319432

I'd go with a single job listening for mediawiki/core master branch which would then simply docker run docker-registry.wikimedia.org/releng/quibble-buster-php74.

Since Quibble 1.5.6, one can pass --change <some change number> to Quibble. It will query Gerrit for the change metadata, clone the repository and fetch the latest patchset of the change. c6dcc8297a801d2c9b75f753b5dd8c49348a1730. That might be the easiest way.

@dancy got the first successful quibble run in the new zuul today: http://zuul.dancy.cloud.releng.team/t/wikimedia/build/ad7cddb6632b45c4b635ada249c53bba/console

Triggered by dancy-test-mw/core!3

And another test demonstrates Depends-On is working:

Shows:

  • GitLab driver for Zuul works as expected (same as Gerrit, afaict)
  • Porting over MediaWiki tests (the equivalent of mediawiki-quibble-apitests-vendor-php74-docker) is possible

Gives us assurance we can run MediaWiki tests.