Page MenuHomePhabricator

Wikibase CI jobs wikibase-repo and wikibase-client broken on REL1_42
Closed, ResolvedPublic

Description

The MediaWiki REL1_42 branch (MW-1.42-release) drops support for PHP 7.4 and 8.0 (T359868), but our wikibase-repo and wikibase-client jobs still run these versions, so they block any backports to the branch. We need to figure out what to do about that.

Event Timeline

Potential options:

(Probably not a blocker for the release, just related to it.)

  • make those jobs run on PHP 8.1 on all branches (After all, we still have other CI jobs to cover PHP 7.4 compatibility while we need it for production.)

I think I like this option best so far; however, we’d want to make sure that moving those jobs to PHP 8.1 doesn’t break them on the older release branches. I tried running PHP 8 tests on REL1_39, and they fail; however, it’s not clear whether the failure seen in quibble-vendor-mysql-php80-noselenium and quibble-vendor-mysql-php81-noselenium would affect the wikibase-repo and wikibase-client jobs too. (If I’m reading the CI output correctly, Wikibase’s composer dependencies, including onoi/message-reporter:1.4.2, were installed before running the unit tests, but then reverted with git clean -xqdf in /workspace/src/extensions/Wikibase; then the separate composer install for MediaWiki and the integration / database tests didn’t install Wikibase’s dependencies. “Error: Class "Onoi\MessageReporter\ObservableMessageReporter" not found” probably just means that all of Wikibase’s dependencies are missing.) It would be great if we could somehow test this. (If there’s no better option, I suppose we could just bump those CI jobs to PHP 8, run a test build on REL1_39, and revert the jobs back to PHP 7.4 if the test build fails.)

I agree on porting wikibase-repo/wikibase-client to php81 (and later, php83); indeed, I was planning on doing this this weekend as part of general CI clean-up, and am kicking myself for forgetting they'd block REL1_42, sorry!

However, for simplicity I'd suggest actually making variants of this job with different PHP versions, so we can (a) leave the old, passing, php74 job for REL1_39 or whatever, at least temporarily, and (b) add e.g. the php83 job to the experimental branch to help the Wikibase team plan ahead.

How does that sound?

Change #1019298 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] [WIP] jjb: Specifcy PHP flavour in Wikibase special quibble jobs

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

Yeah, splitting the job also sounds fine to me.

Change #1020212 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] Zuul [mediawiki/extensions/Wikibase] Disable custom jobs on REL1_42 temporarily

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

Change #1020212 merged by jenkins-bot:

[integration/config@master] Zuul [mediawiki/extensions/Wikibase] Disable custom jobs on REL1_42 temporarily

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

Mentioned in SAL (#wikimedia-releng) [2024-04-16T13:21:35Z] <James_F> Zuul: [mediawiki/extensions/Wikibase] Disable custom jobs on REL1_42 temporarily for T362412

OK, I've disabled the jobs for now, which unblocks merges/etc., but we should actually fix this.

Change #1020216 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] Zuul: [mediawiki/extensions/Wikibase] Run REL1_42 on PHP 8.1 jobs

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

Change #1019298 merged by jenkins-bot:

[integration/config@master] jjb: Specify PHP flavour in Wikibase special quibble jobs, add 81/83

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

Mentioned in SAL (#wikimedia-releng) [2024-05-23T14:03:15Z] <James_F> Zuul: Specify PHP flavour in Wikibase special quibble jobs, add 81/83 for T362412

Change #1020216 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/extensions/Wikibase] Run REL1_42 on PHP 8.1 jobs

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

Mentioned in SAL (#wikimedia-releng) [2024-05-23T14:17:36Z] <James_F> Zuul: [mediawiki/extensions/Wikibase] Run REL1_42 on PHP 8.1 jobs for T362412

Jdforrester-WMF claimed this task.

This should now be resolved.

Thanks! Annoyingly, my past self didn’t write down which specific backports were blocked, but AFAICT there are no open REL1_* changes on Gerrit that were blocked by this, so it looks like we’re all done. (I think the backport in question was this one and it was already fixed by T362412#9717973.)

Thanks! Annoyingly, my past self didn’t write down which specific backports were blocked, but AFAICT there are no open REL1_* changes on Gerrit that were blocked by this, so it looks like we’re all done. (I think the backport in question was this one and it was already fixed by T362412#9717973.)

Yes, but now we're actually running these tests again. :-)

(restoring assignee after column trigger unintentionally cleared it)