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

[integration/config@master] Zuul: [mediawiki/core] Add a non-vendor php81 job for main branch

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

Change 826217 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/core] Add a non-vendor php81 job for main branch

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

Mentioned in SAL (#wikimedia-releng) [2022-09-19T13:50:49Z] <James_F> Zuul: [mediawiki/core] Add a non-vendor php81 job for main branch for T316078

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

[integration/config@master] Zuul: [mediawiki/core] Upgrade PHP 8.0 and 8.1 jobs to full vendor jobs

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

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

[integration/config@master] Zuul: Make PHP 8.0 and PHP 8.1 voting for all skins and extensions

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

Change 836977 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/core] Upgrade PHP 8.0 and 8.1 jobs to full vendor jobs

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

Mentioned in SAL (#wikimedia-releng) [2022-09-30T02:30:34Z] <James_F> Zuul: [mediawiki/core] Upgrade PHP 8.0 and 8.1 jobs to full vendor jobs for T300463 and T316078

Change 836979 merged by jenkins-bot:

[integration/config@master] Zuul: Make PHP 8.0 and PHP 8.1 voting for all skins and extensions

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

Mentioned in SAL (#wikimedia-releng) [2022-09-30T16:46:38Z] <James_F> Zuul: Make PHP 8.0 and PHP 8.1 voting for all skins and extensions in master for T300463 and T316078

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

[integration/config@master] Zuul: Make PHP 8.1 non-voting for all skins and extensions

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

Change 837153 merged by jenkins-bot:

[integration/config@master] Zuul: Make PHP 8.1 non-voting for all skins and extensions

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

Mentioned in SAL (#wikimedia-releng) [2022-09-30T17:07:21Z] <James_F> Zuul: Make PHP 8.1 non-voting for all skins and extensions T316078

Now PHP 8(.0) tests are run on submit, but not when a new (or the first) patchset is uploaded. This can lead to surprises – everything’s green, until one submits the change. Couldn’t the PHP 8 tests be run after uploading patchsets as well?

In T316078#8278300, @Tacsipacsi wrote:

Now PHP 8(.0) tests are run on submit, but not when a new (or the first) patchset is uploaded. This can lead to surprises – everything’s green, until one submits the change. Couldn’t the PHP 8 tests be run after uploading patchsets as well?

We only run the mainline tests on 'test', not the full set. If you want to run the alternative flavours of PHP, run the 'php' pipeline by triggering check php.

The very substance of a surprise is that one doesn’t expect it. If I expect it, I can trigger the php pipeline, but if I don’t, this possibility doesn’t help. As PHP 8 is a breaking change in many ways, and this change was central, so developers of individual extensions may not even be aware of it, the risk of unexpected CI failures is very real. If you want to keep the CI minutes low, couldn’t you add PHP 8.0 and remove some PHP 7.x version instead?

In T316078#8280799, @Tacsipacsi wrote:

The very substance of a surprise is that one doesn’t expect it. If I expect it, I can trigger the php pipeline, but if I don’t, this possibility doesn’t help. As PHP 8 is a breaking change in many ways, and this change was central, so developers of individual extensions may not even be aware of it, the risk of unexpected CI failures is very real. If you want to keep the CI minutes low, couldn’t you add PHP 8.0 and remove some PHP 7.x version instead?

THat's how CI has been configured for years. Last week this is exactly how it ran for 7.2, 7.3, and 7.4. This is not the venue for lobbying for it to change. Please make another task.

In T316078#8280802, @Jdforrester-WMF wrote:

THat's how CI has been configured for years.

What is how it has been configured for years? That a version containing many subtle breaking changes is run only on submit by default? As far as I remember, PHP 7.2, 7.3 and 7.4 didn’t contain many (if any) breaking changes, only new features that could be used for making breaking code changes (e.g. by making type declarations usable at more places) – which didn’t result in immediate CI failures, only after making those code changes. My problem is not that not all versions are tested by default, but that a version that is likely to cause CI failures is not tested by default.

P.S. Reading this message again, it may sound a bit harsh. I’m sorry for that – I really just want to understand you before creating a new task, so that I can address your concerns.

Is this fixed? It looks fixed.

In T316078#8280879, @Tacsipacsi wrote:

In T316078#8280802, @Jdforrester-WMF wrote:

THat's how CI has been configured for years.

What is how it has been configured for years? That a version containing many subtle breaking changes is run only on submit by default?

Yes. For example, when we ran with 5.5 and HHVM, and later HHVM and PHP 7.0, we only ran the HHVM tests in the initial 'test' pipe.

As far as I remember, PHP 7.2, 7.3 and 7.4 didn’t contain many (if any) breaking changes, only new features that could be used for making breaking code changes (e.g. by making type declarations usable at more places) – which didn’t result in immediate CI failures, only after making those code changes. My problem is not that not all versions are tested by default, but that a version that is likely to cause CI failures is not tested by default.

I understand your concern, but we have to balance the needs of the individual developers rarely irritated by such things with the general mass of developers who are sharing a fixed resource.

P.S. Reading this message again, it may sound a bit harsh. I’m sorry for that – I really just want to understand you before creating a new task, so that I can address your concerns.

No worries. It can be frustrating. :-)

In T316078#8340645, @tstarling wrote:

Is this fixed? It looks fixed.

No, not yet.

CI has 8.1 voting for MediaWiki core itself and MediaWiki vendor, but it's not running for extensions/skins and there are some libraries (T307506) whose tests (and so possibly code in untested core usage?) fail. Hence the subsidiary tasks.

@Jdforrester-WMF Tim had the use case for a PHP 8.1 only extension (due to using Fibers). As a result the Zuul config now has a extension-quibble-php81-or-later template with Phan running under php 8.1 as well https://gerrit.wikimedia.org/r/c/integration/config/+/848553 \o/

In T316078#8341694, @Jdforrester-WMF wrote:

CI has 8.1 voting for MediaWiki core itself and MediaWiki vendor, but it's not running for extensions/skins and there are some libraries (T307506) whose tests (and so possibly code in untested core usage?) fail. Hence the subsidiary tasks.

Right. I thought "MW master" in the task title just meant core. Can you clarify the title? T319432 is a parent, but surely WMF production migration does not depend on non-production extensions? But we already have T319065 for production extensions.

In T316078#8355578, @tstarling wrote:

In T316078#8341694, @Jdforrester-WMF wrote:

CI has 8.1 voting for MediaWiki core itself and MediaWiki vendor, but it's not running for extensions/skins and there are some libraries (T307506) whose tests (and so possibly code in untested core usage?) fail. Hence the subsidiary tasks.

Right. I thought "MW master" in the task title just meant core. Can you clarify the title?

Sure.

T319432 is a parent, but surely WMF production migration does not depend on non-production extensions?

General practice is to raise requirements for all repos in one go; non-production repos will have to fix themselves afterwards if not already working, whereas we won't roll CI in a way that breaks production ones.

But we already have T319065 for production extensions.

Yup, which blocks this.

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

[integration/config@master] Zuul: [mediawiki/core] Add PHP 8.1 phan job

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

Change 855046 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/core] Add PHP 8.1 phan job

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

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

[integration/config@master] Zuul: Make PHP 8.1 voting for all quibble items

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

Change 855162 merged by jenkins-bot:

[integration/config@master] Zuul: Make PHP 8.1 voting for all quibble items

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

Mentioned in SAL (#wikimedia-releng) [2022-11-10T01:09:45Z] <James_F> Zuul: Make PHP 8.1 voting for all quibble items for T316078

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

[mediawiki/vendor@master] composer: Disable linting the Match.php file that breaks PHP 8.0

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

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

[integration/config@master] Zuul: [mediawiki/vendor] Test composer lint with PHP 8.0+ too

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

Change 1000928 merged by jenkins-bot:

[mediawiki/vendor@master] composer: Disable linting the Match.php file that breaks PHP 8.0

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

Change 1000929 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/vendor] Test composer lint with PHP 8.0+ too

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

Mentioned in SAL (#wikimedia-releng) [2024-02-14T14:50:19Z] <James_F> Zuul: [mediawiki/vendor] Test composer lint with PHP 8.0+ too for T300463 T316078 T352085 T353362