Switch the default test environment to PHP 8.4

Isn't it a bit too early for that? Still a lot of contrib modules still don't work well on PHP 8.3

solomon.yifru → made their first commit to this issue’s fork.

@danrod this is for core tests pipelines, we test on both PHP 8.4 and 8.3 every day, it has zero effect on contrib module test pipelines which are in the separate 'gitlab_templates' project.

I wonder would it make sense to switch to PHPUnit 11 for 8.4 too? And let 8.3 and below onto PHPUnit 10? https://stitcher.io/blog/php-version-stats-january-2025

In start of July first alpha of PHP 8.5 will arrive so no reason to wait

added https://packagist.org/php-statistics to summary

Added commit to switch MySQL to 8.4 (LTS) for the default pipeline

Ref https://dev.mysql.com/doc/refman/8.4/en/mysql-releases.html

Note: MySQL 8.0 is a Bugfix series that preceded the LTS release model.

lets do it!

8.0.34+ will transition to only bug fixes until 8.0 End-Of-Life (EOL) scheduled for April-2026

So nightly testing is good enough for support https://dev.mysql.com/blog-archive/introducing-mysql-innovation-and-long...

clearer title

Committed/pushed to 11.x, thanks!

catch → closed merge request !11947

@catch thank you, curious how perf tests are executed (I have no access to start'em) and how it vary from 8.3 at the end

This caused a new, frequent, random test failure, it looks like it might be an issue with the images maybe. 🐛 [random test failure] Drupal\FunctionalTests\Bootstrap\UncaughtExceptionTest::testLostDatabaseConnection Active .

Reverted here for now, let's re-commit with that fixed one way or the other.

FTR, weirdly, the revert also fixed the build tests failure lately in 🌱 [meta] Support PHPUnit 11 in Drupal 10 Postponed . Ideally, it would preferable to postpone this one on that if there is interest to get PHPUnit in 11.2 so that we do not have to play catch there.

andypost → reopened merge request !11947

Re-opened MR as MySQL 8.4 image is fixed via 🐛 Fix deprecated MySQL native passwords Active

See https://git.drupalcode.org/issue/drupal-3521851/-/jobs/5110756

I see the linked issue has been merged to "production" and "dev" so assuming that's what we use. So would this be good to go again

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Since bumping the default to 8.4 also forces the PHPUnit 11 bump for the PHPStan job, we now have a few more PHPUnit 11 errors that we should add to baseline.

I do not understand why despite adding the baseline update, PHPStan still fails.

Maybe bump PHPstan in separate issue?

Tried #28.

Keeping PHPStan job on PHP 8.3 let the job pass, but the Build tests failure seems legitimate.

Spinned off 📌 [CI] Run PHPStan job on PHP 8.4 Active

The Build test failure had the same root cause of 📌 [CI] Run PHPStan job on PHP 8.4 Active .

composer run-script drupal-phpunit-upgrade-check, run during the PHPCS lint job, flashes a new composer.lock file as well as the packages metadata json files. But only the /vendor folder is stored as an artifact, not the updated files.

The MR now is built on top of the one in 📌 [CI] Run PHPStan job on PHP 8.4 Active ; it is extended by including also the updated files in the PHPCS artifacts.

The downside: now the composer build artifacts as built by PHP 8.4 are also used by the PHP 8.3 tests of the child pipelines.

Unfortunately the needs:job entry does not accept variables.

leaning on pipeline passing for this one.

Sorry, better wait for #3497431: Deprecate TestDiscovery test file scanning, use PHPUnit API instead that is now partially overlapping here too.