Potential options:

• Make those jobs run on PHP 8.1 for the REL1_42 branch, if possible.
• If not: make those jobs run on PHP 8.1 on all branches, either after T319432: Migrate WMF production from PHP 7.4 to PHP 8.1 is done, or earlier. (After all, we still have other CI jobs to cover PHP 7.4 compatibility while we need it for production.)
• Drop the jobs from the REL1_42 branch.
• Add some kind of awful hack that reverts T359868: Drop PHP 7.4 and 8.0 support from MediaWiki 1.42; require PHP 8.1+ in those jobs and makes MediaWiki not disclaim support for PHP 7.4 anymore. (After all, most of the actual code should still support that version.)
• …?

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

In T362412#9710114, @Lucas_Werkmeister_WMDE wrote:

• 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